[Python-Dev] setUpClass and setUpModule in unittest

Michael Foord fuzzyman at voidspace.org.uk
Tue Feb 9 17:42:50 CET 2010


Hello all,

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'm pretty sure I can introduce setUpClass and setUpModule without 
breaking compatibility with existing unittest extensions or backwards 
compatibility issues - with the possible exception of test sorting. 
Where you have a class level setUp (for example creating a database 
connection) you don't want the tearDown executed a *long* time after the 
setUp. In the presence of class or module level setUp /tearDown (but 
only if they are used) I would expect test sorting to only sort within 
the class or module [1]. I will introduce the setUp and tearDown as new 
'tests' - so failures are reported separately, and all tests in the 
class / module will have an explicit skip in the event of a setUp failure.

A *better* (more general) solution for sharing and managing resources 
between tests is to use something like TestResources by Robert Collins. 
http://pypi.python.org/pypi/testresources/

A minimal example of using test resources shows very little boilerplate 
overhead from what setUpClass (etc) would need, and with the addition of 
some helper functions could be almost no overhead. I've challenged 
Robert that if he can provide examples of using Test Resources to meet 
the class and module level use-cases then I would support bringing Test 
Resources into the standard library as part of unittest (modulo 
licensing issues which he is happy to work on).

I'm not sure what response I expect from this email, and neither option 
will be implemented without further discussion - possibly at the PyCon 
sprints - but I thought I would make it clear what the possible 
directions are.

All the best,

Michael Foord

[1] I *could* allow sorting of all tests within a module, inserting the 
setUpClass / tearDownClass in the right place after the sort. It would 
probably be better to group tests per class anyway and in fact the 
existing suite sorting support may do this already (in which case it 
isn't an issue) - I haven't looked into the implementation.

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.




More information about the Python-Dev mailing list