[Python-Dev] setUpClass and setUpModule in unittest

[exarkun at twistedmatrix.com]

On 08:27 pm, guido at python.org wrote:
>On Fri, Feb 12, 2010 at 12:20 PM,  <exarkun at twistedmatrix.com> wrote:
>>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.
>
>So is there a way to associate a "cost" with a resource? I may have
>one resource which is simply a /tmp subdirectory (very cheap) and
>another that requires starting a database service (very expensive).

I don't think so.  From the docs, "This TestSuite will introspect all 
the test cases it holds directly and if they declare needed resources, 
will run the tests in an order that attempts to minimise the number of 
setup and tear downs required.".
>
>>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.
>
>I admire the approach, though I am skeptical. We have a thing to split
>up tests at Google which looks at past running times for tests to make
>an informed opinion. Have you thought of that?
>>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.
>
>How does your code know the constraints?

To be clear, aside from OptimisingTestSuite, I don't think testresources 
implements any of the features I talked about.  They're just things one 
might want to and be able to implement, given a test suite which uses 
testresources.
>
>>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.
>
>I guess this requires some trust in the system. :-)

Jean-Paul