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 <hol...@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 <hol...@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 > > > _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
