[Python-Dev] setUpClass and setUpModule in unittest

Holger Krekel holger.krekel at gmail.com
Tue Feb 9 23:34:00 CET 2010


On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Michael Foord <fuzzyman at voidspace.org.uk> writes:
>
>> The next 'big' change to unittest will (may?) be the introduction of
>> class and module level setUp and tearDown. This was discussed on
>> Python-ideas and Guido supported them. They can be useful but are also
>> very easy to abuse (too much shared state, monolithic test classes and
>> modules). Several authors of other Python testing frameworks spoke up
>> *against* them, but several *users* of test frameworks spoke up in
>> favour of them. ;-)
>
> I think the perceived need for these is from people trying to use the
> ‘unittest’ API for test that are *not* unit tests.
>
> That is, people have a need for integration tests (test this module's
> interaction with some other module) or system tests (test the behaviour
> of the whole running system). They then try to crowbar those tests into
> ‘unittest’ and finding it lacking, since ‘unittest’ is designed for
> tests of function-level units, without persistent state between those
> test cases.
>
> Is there a better third-party framework for use in these cases? As
> Olemis points out later in this thread, I don't think it's good for the
> ‘unittest’ module to keep growing for uses that aren't focussed on unit
> tests (as contrasted with other kinds of tests).

My general view these days is that for unit tests there is practically not
much of a a difference in using unittest, nose or py.test (give or
take reporting
niceness and flexibility).  However, Functional and integration tests
involve more
complex fixture management and i came to find the setup/teardown on
classes and modules lacking.  Which is why there is testresources from
Rob and funcargs in py.test. The latter allow to setup and teardown
resources from a fixture factory which can determine the setup/teardown scope
and perform whole-session caching without changing test code.  In my
Pycon testing tutorial (http://tinyurl.com/ya6b3vr ) i am going to exercise
it in depth with beginners and here are docs: http://pytest.org/funcargs.html
One nice bit is that you can for a given test module issue "py.test --funcargs"
and get a list of resources you can use in your test function - by simply
specifying them in the test function.

In principle it's possible to port this approach to the stdlib - actually i
consider to do it for the std-unittest- running part of py.test because
people asked for it - if that proves useful i can imagine to refine it
and offer it for inclusion.

cheers,
holger


More information about the Python-Dev mailing list