[py-dev] migration from 1.3 to 2.0
Hi Holger and list members, I have been using py.test for some time after switching from nose and quite happy with it. However, when migrating from 1.3.1 to 2.0.2 I hit a couple of snags, which makes me hesitate. Perhaps you can help me. 1. Just to clear the point. I understand from another post that option_xxxx variables in conftest.py are gone and recommended replacement is to use pytest_cmdline_preparse(). Is that so? 2. The new behavior is that even if you run py.test --help, the pytest_configure() is still run. In my case pytest_configure() does quite a bit of heavy lifting and raises exceptions at wrong parameters. The result is that if the parameter is wrong I cannot use help to find out what is the right parameter. Of course, the workaround could be: def pytest_configure(config): if config.getvalue('help'): return ... but it seems ugly. Am I in a wrong hook? 3. In my pytest_configure() there are numerous conditions when it can fail. For this conditions I have exceptions with specially crafted messages, intended for different people. Now they are gone, replaced by a long and scary listing with every line prepended with INTERNALERROR. What is internal about it? Can I continue managing my configuration errors? Thanks, Vyacheslav
Hi Vyachselav, On Tue, Apr 05, 2011 at 11:42 -0400, Vyacheslav Rafalskiy wrote:
Hi Holger and list members,
I have been using py.test for some time after switching from nose and quite happy with it. However, when migrating from 1.3.1 to 2.0.2 I hit a couple of snags, which makes me hesitate. Perhaps you can help me.
can try but am only online intermittently currently.
1. Just to clear the point. I understand from another post that option_xxxx variables in conftest.py are gone and recommended replacement is to use pytest_cmdline_preparse(). Is that so?
Not exactly. You can use a .ini file to add command line options: http://pytest.org/customize.html#adding-default-options Or do you need to do something more dynamic? In that case you could play with pytest_cmdline_preparse, indeed.
2. The new behavior is that even if you run py.test --help, the pytest_configure() is still run. In my case pytest_configure() does quite a bit of heavy lifting and raises exceptions at wrong parameters. The result is that if the parameter is wrong I cannot use help to find out what is the right parameter. Of course, the workaround could be:
def pytest_configure(config): if config.getvalue('help'): return ...
but it seems ugly. Am I in a wrong hook?
You could try pytest_sessionstart(session) and access session.config for the config object.
3. In my pytest_configure() there are numerous conditions when it can fail. For this conditions I have exceptions with specially crafted messages, intended for different people. Now they are gone, replaced by a long and scary listing with every line prepended with INTERNALERROR. What is internal about it? Can I continue managing my configuration errors?
Sure, you should be able to. I guess it was a bit of an incident that failures in pytest_configure were shown nicely. I am not quite sure immediately what the best way to relay "global" configuration messages to the user is. If you'd use "funcargs" and the "session" scope for setting up resources then it would show nicely. Feel free to open a feature/enhancement request to have py.test show failures in sessionstart or configure hooks in a way that helps you. This way we can write a specific test and make sure it works also in the future. best, holger
Thanks Holger, On Tue, Apr 5, 2011 at 4:16 PM, holger krekel <holger@merlinux.eu> wrote:
Hi Vyachselav,
On Tue, Apr 05, 2011 at 11:42 -0400, Vyacheslav Rafalskiy wrote:
Hi Holger and list members,
I have been using py.test for some time after switching from nose and quite happy with it. However, when migrating from 1.3.1 to 2.0.2 I hit a couple of snags, which makes me hesitate. Perhaps you can help me.
can try but am only online intermittently currently.
1. Just to clear the point. I understand from another post that option_xxxx variables in conftest.py are gone and recommended replacement is to use pytest_cmdline_preparse(). Is that so?
Not exactly. You can use a .ini file to add command line options:
I wouldn't want to maintain an extra config file. I already have conftest.py with a lot of hardcoded stuff, a bit more does not hurt. Moreover, if you put it like def pytest_cmdline_preparse(args): args[0:0] = [ '--verbose', '--capture=no', ] it looks even cleaner than using option_xxxx variables in spite of a bit of boilerplate.
3. In my pytest_configure() there are numerous conditions when it can fail. For this conditions I have exceptions with specially crafted messages, intended for different people. Now they are gone, replaced by a long and scary listing with every line prepended with INTERNALERROR. What is internal about it? Can I continue managing my configuration errors?
Sure, you should be able to. I guess it was a bit of an incident that failures in pytest_configure were shown nicely. I am not quite sure immediately what the best way to relay "global" configuration messages to the user is. If you'd use "funcargs" and the "session" scope for setting up resources then it would show nicely. Feel free to open a feature/enhancement request to have py.test show failures in sessionstart or configure hooks in a way that helps you. This way we can write a specific test and make sure it works also in the future.
If I understand correctly, using funcargs means that every test function of hundreds I have in several suites should include a reference to the global setup funcarg. It seems a non-starter. I guess I will stick to the old version and try to think of something to enter in a feature request. Vyacheslav
3. In my pytest_configure() there are numerous conditions when it can fail. For this conditions I have exceptions with specially crafted messages, intended for different people. Now they are gone, replaced by a long and scary listing with every line prepended with INTERNALERROR. What is internal about it? Can I continue managing my configuration errors?
Sure, you should be able to. I guess it was a bit of an incident that failures in pytest_configure were shown nicely. I am not quite sure immediately what the best way to relay "global" configuration messages to the user is. If you'd use "funcargs" and the "session" scope for setting up resources then it would show nicely. Feel free to open a feature/enhancement request to have py.test show failures in sessionstart or configure hooks in a way that helps you. This way we can write a specific test and make sure it works also in the future.
If I understand correctly, using funcargs means that every test function of hundreds I have in several suites should include a reference to the global setup funcarg. It seems a non-starter.
I guess I will stick to the old version and try to think of something to enter in a feature request.
Vyacheslav
Looks like I solved my main problem with a monkey patch, admittedly a brutal one import sys import _pytest.core def notify_exception(self, excinfo): excrepr = excinfo.getrepr(style='native') sys.stderr.write(excrepr) _pytest.core.PluginManager.notify_exception = notify_exception
On Wed, Apr 06, 2011 at 12:37 -0400, Vyacheslav Rafalskiy wrote:
Not exactly. You can use a .ini file to add command line options:
I wouldn't want to maintain an extra config file. I already have conftest.py with a lot of hardcoded stuff, a bit more does not hurt. Moreover, if you put it like
def pytest_cmdline_preparse(args): args[0:0] = [ '--verbose', '--capture=no', ]
it looks even cleaner than using option_xxxx variables in spite of a bit of boilerplate.
Sure, if you have a root conftest.py anyway that works. Note that you can put the .ini config into a setup.cfg as well which is used by the upcoming python package distribution as well (and setuptools).
3. In my pytest_configure() there are numerous conditions when it can fail. For this conditions I have exceptions with specially crafted messages, intended for different people. Now they are gone, replaced by a long and scary listing with every line prepended with INTERNALERROR. What is internal about it? Can I continue managing my configuration errors?
Sure, you should be able to. I guess it was a bit of an incident that failures in pytest_configure were shown nicely. I am not quite sure immediately what the best way to relay "global" configuration messages to the user is. If you'd use "funcargs" and the "session" scope for setting up resources then it would show nicely. Feel free to open a feature/enhancement request to have py.test show failures in sessionstart or configure hooks in a way that helps you. This way we can write a specific test and make sure it works also in the future.
If I understand correctly, using funcargs means that every test function of hundreds I have in several suites should include a reference to the global setup funcarg. It seems a non-starter.
I guess I will stick to the old version and try to think of something to enter in a feature request.
sure, makes sense. isn't your main issue that upon actual test start (after collection) you want to do some configuration steps which might result in error conditions which you'd like to see nicely reported to the user? (sidenote: configure and even sessionstart hooks are both a bit not 100% right because they happen even on the master side of a distributed test run and the master side does not collect or run tests at all) best, holger
Vyacheslav
3. In my pytest_configure() there are numerous conditions when it can fail. For this conditions I have exceptions with specially crafted messages, intended for different people. Now they are gone, replaced by a long and scary listing with every line prepended with INTERNALERROR. What is internal about it? Can I continue managing my configuration errors?
Sure, you should be able to. I guess it was a bit of an incident that failures in pytest_configure were shown nicely. I am not quite sure immediately what the best way to relay "global" configuration messages to the user is. If you'd use "funcargs" and the "session" scope for setting up resources then it would show nicely. Feel free to open a feature/enhancement request to have py.test show failures in sessionstart or configure hooks in a way that helps you. This way we can write a specific test and make sure it works also in the future.
If I understand correctly, using funcargs means that every test function of hundreds I have in several suites should include a reference to the global setup funcarg. It seems a non-starter.
I guess I will stick to the old version and try to think of something to enter in a feature request.
sure, makes sense. isn't your main issue that upon actual test start (after collection) you want to do some configuration steps which might result in error conditions which you'd like to see nicely reported to the user?
That's exactly my point.
(sidenote: configure and even sessionstart hooks are both a bit not 100% right because they happen even on the master side of a distributed test run and the master side does not collect or run tests at all)
I see. Perhaps something like setup_package() in the top-level __init__.py could be a solution? Vyacheslav
On Thu, Apr 07, 2011 at 12:29 -0400, Vyacheslav Rafalskiy wrote:
3. In my pytest_configure() there are numerous conditions when it can fail. For this conditions I have exceptions with specially crafted messages, intended for different people. Now they are gone, replaced by a long and scary listing with every line prepended with INTERNALERROR. What is internal about it? Can I continue managing my configuration errors?
Sure, you should be able to. I guess it was a bit of an incident that failures in pytest_configure were shown nicely. I am not quite sure immediately what the best way to relay "global" configuration messages to the user is. If you'd use "funcargs" and the "session" scope for setting up resources then it would show nicely. Feel free to open a feature/enhancement request to have py.test show failures in sessionstart or configure hooks in a way that helps you. This way we can write a specific test and make sure it works also in the future.
If I understand correctly, using funcargs means that every test function of hundreds I have in several suites should include a reference to the global setup funcarg. It seems a non-starter.
I guess I will stick to the old version and try to think of something to enter in a feature request.
sure, makes sense. isn't your main issue that upon actual test start (after collection) you want to do some configuration steps which might result in error conditions which you'd like to see nicely reported to the user?
That's exactly my point.
(sidenote: configure and even sessionstart hooks are both a bit not 100% right because they happen even on the master side of a distributed test run and the master side does not collect or run tests at all)
I see. Perhaps something like setup_package() in the top-level __init__.py could be a solution?
I guess you mean an __init__.py file of a test directory. With a layout of test dirs within an application this might mean one has to put this setup into the main package __init__.py and mixing test code and application code is often not a good idea. So i'd rather put it into a conftest.py file as a normal hook. Maybe "pytest_pyfunc_setup(request)" would be good where request is the same object as for the funcarg factories. You could then write: # content of conftest.py def pytest_pyfunc_setup(request): val = request.cached_setup(setup=makeval, scope="session") # use val for some global setting of the package Alternatively we could see to call something like: def pytest_setup_testloop(config): val = makeval() # use val for some global setting of the package def pytest_teardown_testloop(config): ... which would be called once for a test process. best, holger
Vyacheslav _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
On Sat, Apr 30, 2011 at 10:22 AM, holger krekel <holger@merlinux.eu> wrote:
On Thu, Apr 07, 2011 at 12:29 -0400, Vyacheslav Rafalskiy wrote:
(sidenote: configure and even sessionstart hooks are both a bit not 100% right because they happen even on the master side of a distributed test run and the master side does not collect or run tests at all)
I see. Perhaps something like setup_package() in the top-level __init__.py could be a solution?
I guess you mean an __init__.py file of a test directory. With a layout of test dirs within an application this might mean one has to put this setup into the main package __init__.py and mixing test code and application code is often not a good idea.
Yes, exactly. In my case of functional testing I don't even have application code here. When I start the tests I tell the runner where in the network the system under test is.
So i'd rather put it into a conftest.py file as a normal hook. Maybe "pytest_pyfunc_setup(request)" would be good where request is the same object as for the funcarg factories.
You could then write:
# content of conftest.py def pytest_pyfunc_setup(request): val = request.cached_setup(setup=makeval, scope="session") # use val for some global setting of the package
Alternatively we could see to call something like:
def pytest_setup_testloop(config): val = makeval() # use val for some global setting of the package
def pytest_teardown_testloop(config): ...
which would be called once for a test process.
The reason why I suggested setup_package() is that you already have setup_function, setup_method, setup_class and setup_module so the former would just complete the line-up. And the natural place for it would be __init__.py of that package. On the other hand, you can put conftest.py in every folder, which can do precisely the same thing as well as many others. The question is which way is more intuitive and results in cleaner code. The answer is perhaps "It depends". I like setup_module(module) because it lets me dump the configuration straight into the namespace where I use it and setup_package(package) could do the same. But all in all, whatever works is fine with me. Thanks, Vyacheslav
best, holger
Vyacheslav _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
On Mon, May 02, 2011 at 17:40 -0400, Vyacheslav Rafalskiy wrote:
On Sat, Apr 30, 2011 at 10:22 AM, holger krekel <holger@merlinux.eu> wrote:
On Thu, Apr 07, 2011 at 12:29 -0400, Vyacheslav Rafalskiy wrote:
(sidenote: configure and even sessionstart hooks are both a bit not 100% right because they happen even on the master side of a distributed test run and the master side does not collect or run tests at all)
I see. Perhaps something like setup_package() in the top-level __init__.py could be a solution?
I guess you mean an __init__.py file of a test directory. With a layout of test dirs within an application this might mean one has to put this setup into the main package __init__.py and mixing test code and application code is often not a good idea.
Yes, exactly. In my case of functional testing I don't even have application code here. When I start the tests I tell the runner where in the network the system under test is.
So i'd rather put it into a conftest.py file as a normal hook. Maybe "pytest_pyfunc_setup(request)" would be good where request is the same object as for the funcarg factories.
You could then write:
# content of conftest.py def pytest_pyfunc_setup(request): val = request.cached_setup(setup=makeval, scope="session") # use val for some global setting of the package
Alternatively we could see to call something like:
def pytest_setup_testloop(config): val = makeval() # use val for some global setting of the package
def pytest_teardown_testloop(config): ...
which would be called once for a test process.
The reason why I suggested setup_package() is that you already have setup_function, setup_method, setup_class and setup_module so the former would just complete the line-up. And the natural place for it would be __init__.py of that package.
On the other hand, you can put conftest.py in every folder, which can do precisely the same thing as well as many others. The question is which way is more intuitive and results in cleaner code. The answer is perhaps "It depends".
I like setup_module(module) because it lets me dump the configuration straight into the namespace where I use it and setup_package(package) could do the same.
good line of reasoning. It's mostly my intuition making me hesitant to add setup_package like you suggest. And i wonder what it is about :) Maybe it's that the root namespace of a test directory is often called "testing" or "tests" (the "test" one is taken by Python stdlib already). And therefore you would end up having to do "import testing" and then use global state with something like "testing.STATE". But i guess this doesn't look so bad to you, does it? :) (The plugin/conftest system is designed such that it hardly requires any imports to manage test state.) Any more opinions on setup_package(package)? If others find it useful as well, i will consider introducing it with pytest-2.1. best, holger
On Tue, May 3, 2011 at 5:48 AM, holger krekel <holger@merlinux.eu> wrote:
On Mon, May 02, 2011 at 17:40 -0400, Vyacheslav Rafalskiy wrote:
On Sat, Apr 30, 2011 at 10:22 AM, holger krekel <holger@merlinux.eu> wrote:
On Thu, Apr 07, 2011 at 12:29 -0400, Vyacheslav Rafalskiy wrote:
(sidenote: configure and even sessionstart hooks are both a bit not 100% right because they happen even on the master side of a distributed test run and the master side does not collect or run tests at all)
I see. Perhaps something like setup_package() in the top-level __init__.py could be a solution?
I guess you mean an __init__.py file of a test directory. With a layout of test dirs within an application this might mean one has to put this setup into the main package __init__.py and mixing test code and application code is often not a good idea.
Yes, exactly. In my case of functional testing I don't even have application code here. When I start the tests I tell the runner where in the network the system under test is.
So i'd rather put it into a conftest.py file as a normal hook. Maybe "pytest_pyfunc_setup(request)" would be good where request is the same object as for the funcarg factories.
You could then write:
# content of conftest.py def pytest_pyfunc_setup(request): val = request.cached_setup(setup=makeval, scope="session") # use val for some global setting of the package
Alternatively we could see to call something like:
def pytest_setup_testloop(config): val = makeval() # use val for some global setting of the package
def pytest_teardown_testloop(config): ...
which would be called once for a test process.
The reason why I suggested setup_package() is that you already have setup_function, setup_method, setup_class and setup_module so the former would just complete the line-up. And the natural place for it would be __init__.py of that package.
On the other hand, you can put conftest.py in every folder, which can do precisely the same thing as well as many others. The question is which way is more intuitive and results in cleaner code. The answer is perhaps "It depends".
I like setup_module(module) because it lets me dump the configuration straight into the namespace where I use it and setup_package(package) could do the same.
good line of reasoning. It's mostly my intuition making me hesitant to add setup_package like you suggest. And i wonder what it is about :) Maybe it's that the root namespace of a test directory is often called "testing" or "tests" (the "test" one is taken by Python stdlib already). And therefore you would end up having to do "import testing" and then use global state with something like "testing.STATE". But i guess this doesn't look so bad to you, does it? :) (The plugin/conftest system is designed such that it hardly requires any imports to manage test state.)
Any more opinions on setup_package(package)? If others find it useful as well, i will consider introducing it with pytest-2.1.
I guess I will have to withdraw the idea. Having to explicitly import the test package does not look nice at all. conftest.py rules! As to the two alternatives above I'd rather use pytest_setup_testloop(config) with direct access to config. Regards, Vyacheslav
best, holger
Hey Vyacheslav, On Wed, May 04, 2011 at 10:53 -0400, Vyacheslav Rafalskiy wrote:
On Tue, May 3, 2011 at 5:48 AM, holger krekel <holger@merlinux.eu> wrote:
On Mon, May 02, 2011 at 17:40 -0400, Vyacheslav Rafalskiy wrote:
On Sat, Apr 30, 2011 at 10:22 AM, holger krekel <holger@merlinux.eu> wrote:
On Thu, Apr 07, 2011 at 12:29 -0400, Vyacheslav Rafalskiy wrote:
(sidenote: configure and even sessionstart hooks are both a bit not 100% right because they happen even on the master side of a distributed test run and the master side does not collect or run tests at all)
I see. Perhaps something like setup_package() in the top-level __init__.py could be a solution?
I guess you mean an __init__.py file of a test directory. With a layout of test dirs within an application this might mean one has to put this setup into the main package __init__.py and mixing test code and application code is often not a good idea.
Yes, exactly. In my case of functional testing I don't even have application code here. When I start the tests I tell the runner where in the network the system under test is.
So i'd rather put it into a conftest.py file as a normal hook. Maybe "pytest_pyfunc_setup(request)" would be good where request is the same object as for the funcarg factories.
You could then write:
# content of conftest.py def pytest_pyfunc_setup(request): val = request.cached_setup(setup=makeval, scope="session") # use val for some global setting of the package
Alternatively we could see to call something like:
def pytest_setup_testloop(config): val = makeval() # use val for some global setting of the package
def pytest_teardown_testloop(config): ...
which would be called once for a test process.
The reason why I suggested setup_package() is that you already have setup_function, setup_method, setup_class and setup_module so the former would just complete the line-up. And the natural place for it would be __init__.py of that package.
On the other hand, you can put conftest.py in every folder, which can do precisely the same thing as well as many others. The question is which way is more intuitive and results in cleaner code. The answer is perhaps "It depends".
I like setup_module(module) because it lets me dump the configuration straight into the namespace where I use it and setup_package(package) could do the same.
good line of reasoning. It's mostly my intuition making me hesitant to add setup_package like you suggest. And i wonder what it is about :) Maybe it's that the root namespace of a test directory is often called "testing" or "tests" (the "test" one is taken by Python stdlib already). And therefore you would end up having to do "import testing" and then use global state with something like "testing.STATE". But i guess this doesn't look so bad to you, does it? :) (The plugin/conftest system is designed such that it hardly requires any imports to manage test state.)
Any more opinions on setup_package(package)? If others find it useful as well, i will consider introducing it with pytest-2.1.
I guess I will have to withdraw the idea. Having to explicitly import the test package does not look nice at all. conftest.py rules!
As to the two alternatives above I'd rather use pytest_setup_testloop(config) with direct access to config.
I am now pondering following your original intention and introduce a "setup_directory" to be put into conftest.py files. You could then access the config object via pytest.config. Would that make sense to you as well? best, holger
Regards, Vyacheslav
best, holger
Hey again, On Sun, May 29, 2011 at 07:43 +0000, holger krekel wrote:
good line of reasoning. It's mostly my intuition making me hesitant to add setup_package like you suggest. And i wonder what it is about :) Maybe it's that the root namespace of a test directory is often called "testing" or "tests" (the "test" one is taken by Python stdlib already). And therefore you would end up having to do "import testing" and then use global state with something like "testing.STATE". But i guess this doesn't look so bad to you, does it? :) (The plugin/conftest system is designed such that it hardly requires any imports to manage test state.)
Any more opinions on setup_package(package)? If others find it useful as well, i will consider introducing it with pytest-2.1.
I guess I will have to withdraw the idea. Having to explicitly import the test package does not look nice at all. conftest.py rules!
As to the two alternatives above I'd rather use pytest_setup_testloop(config) with direct access to config.
I am now pondering following your original intention and introduce a "setup_directory" to be put into conftest.py files. You could then access the config object via pytest.config. Would that make sense to you as well?
To elaborate a wee bit: * setup_directory would be guranteed to be called for any test (both python, doctest or other test) within the directory hierarchy of the conftest.py dir and before any setup_module/class etc. is called. * teardown_directory would be guranteed to be called when a test is run that is not in the directory hierarchy. * if neccessary one can have setup_directory push test related state to some global module (from which tests could import for example) i am not yet sure about the idea but i guess it would be somewhat natural and complete the setup_*/teardown_* xUnit style fixture methods. holger
best, holger
Regards, Vyacheslav
best, holger
On Sun, May 29, 2011 at 3:59 AM, holger krekel <holger@merlinux.eu> wrote:
Hey again,
On Sun, May 29, 2011 at 07:43 +0000, holger krekel wrote:
good line of reasoning. It's mostly my intuition making me hesitant to add setup_package like you suggest. And i wonder what it is about :) Maybe it's that the root namespace of a test directory is often called "testing" or "tests" (the "test" one is taken by Python stdlib already). And therefore you would end up having to do "import testing" and then use global state with something like "testing.STATE". But i guess this doesn't look so bad to you, does it? :) (The plugin/conftest system is designed such that it hardly requires any imports to manage test state.)
Any more opinions on setup_package(package)? If others find it useful as well, i will consider introducing it with pytest-2.1.
I guess I will have to withdraw the idea. Having to explicitly import the test package does not look nice at all. conftest.py rules!
As to the two alternatives above I'd rather use pytest_setup_testloop(config) with direct access to config.
I am now pondering following your original intention and introduce a "setup_directory" to be put into conftest.py files. You could then access the config object via pytest.config. Would that make sense to you as well?
To elaborate a wee bit:
* setup_directory would be guranteed to be called for any test (both python, doctest or other test) within the directory hierarchy of the conftest.py dir and before any setup_module/class etc. is called.
* teardown_directory would be guranteed to be called when a test is run that is not in the directory hierarchy.
* if neccessary one can have setup_directory push test related state to some global module (from which tests could import for example)
i am not yet sure about the idea but i guess it would be somewhat natural and complete the setup_*/teardown_* xUnit style fixture methods.
holger
Sounds great to me. Not much to add. Perhaps a parameter, say directory_config, which can then be imported by a test module like for example from pytest import directory_config This object could have different meaning depending on the directory where the test module resides. Vyacheslav
On Mon, May 30, 2011 at 14:24 -0400, Vyacheslav Rafalskiy wrote:
On Sun, May 29, 2011 at 3:59 AM, holger krekel <holger@merlinux.eu> wrote:
On Sun, May 29, 2011 at 07:43 +0000, holger krekel wrote:
good line of reasoning. It's mostly my intuition making me hesitant to add setup_package like you suggest. And i wonder what it is about :) Maybe it's that the root namespace of a test directory is often called "testing" or "tests" (the "test" one is taken by Python stdlib already). And therefore you would end up having to do "import testing" and then use global state with something like "testing.STATE". But i guess this doesn't look so bad to you, does it? :) (The plugin/conftest system is designed such that it hardly requires any imports to manage test state.)
Any more opinions on setup_package(package)? If others find it useful as well, i will consider introducing it with pytest-2.1.
I guess I will have to withdraw the idea. Having to explicitly import the test package does not look nice at all. conftest.py rules!
As to the two alternatives above I'd rather use pytest_setup_testloop(config) with direct access to config.
I am now pondering following your original intention and introduce a "setup_directory" to be put into conftest.py files. You could then access the config object via pytest.config. Would that make sense to you as well?
To elaborate a wee bit:
* setup_directory would be guranteed to be called for any test (both python, doctest or other test) within the directory hierarchy of the conftest.py dir and before any setup_module/class etc. is called.
* teardown_directory would be guranteed to be called when a test is run that is not in the directory hierarchy.
* if neccessary one can have setup_directory push test related state to some global module (from which tests could import for example)
i am not yet sure about the idea but i guess it would be somewhat natural and complete the setup_*/teardown_* xUnit style fixture methods.
holger
Sounds great to me. Not much to add. Perhaps a parameter, say directory_config, which can then be imported by a test module like for example
from pytest import directory_config
This object could have different meaning depending on the directory where the test module resides.
This suggestion would replicate funcarg-functionality which allows to provide different/adapted resources to test modules from conftest.py files. I'd rather like to think about generally giving access to funcarg resources from xUnit setup functions which would enlarge what you can do from xUnit fixtures. Meanwhile, we could maybe introduce a global "pytest.appdata" object which can be used for passing state between various places in test like setup_directory or hooks and test methods or other setup methods. Several python packages (particularly web stuff) have global data anyway and maybe it's best to provide one managed storage for it. best, holger
Vyacheslav
participants (2)
-
holger krekel -
Vyacheslav Rafalskiy