[py-dev] migration from 1.3 to 2.0

holger krekel holger at merlinux.eu
Sun May 29 09:43:27 CEST 2011


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 at 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 at 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
> >
> 



More information about the Pytest-dev mailing list