[Python-Dev] setUpClass and setUpModule in unittest
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Fri Feb 12 21:20:51 CET 2010
On 07:48 pm, guido at python.org wrote:
>On Fri, Feb 12, 2010 at 7:49 AM, Michael Foord
><fuzzyman at voidspace.org.uk> wrote:
>>My *hope* is that we provide a general solution, possibly based on all
>>or
>>part of Test Resources, with an easy mechanism for the setUpClass and
>>setUpModule but also solves the more general case of sharing fixtures
>>between tests. If that doesn't turn out to be possible then we'll go
>>for a
>>straight implementation of setUpClass / setUpModule. I'm hoping I can
>>get
>>this together in time for the PyCon sprints...
>>Do you have a reference for Test Resources?
http://pypi.python.org/pypi/testresources/0.2.2
>[snip]
>>However from this example I *cannot* guess whether those resources are
>set up and torn down per test or per test class. Also the notation
The idea is that you're declaring what the tests need in order to work.
You're not explicitly defining the order in which things are set up and
torn down. That is left up to another part of the library to determine.
One such other part, OptimisingTestSuite, will look at *all* of your
tests and find an order which involves the least redundant effort.
You might have something else that breaks up the test run across
multiple processes and uses the resource declarations to run all tests
requiring one thing in one process and all tests requiring another thing
somewhere else.
You might have still something else that wants to completely randomize
the order of tests, and sets up all the resources at the beginning and
tears them down at the end. Or you might need to be more
memory/whatever conscious than that, and do each set up and tear down
around each test.
The really nice thing here is that you're not constrained in how you
group your tests into classes and modules by what resources you want to
use in them. You're free to group them by what they're logically
testing, or in whatever other way you wish.
Jean-Paul
More information about the Python-Dev
mailing list