[py-dev] migration from 1.3 to 2.0

[Vyacheslav Rafalskiy]

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.

Regards,
Vyacheslav

>
> best,
> holger
>