[Python-ideas] Test Class setup and teardown in unittest

[Michael Foord]

On 21/01/2010 01:37, Robert Collins wrote:
> On Wed, 2010-01-20 at 19:38 -0500, Mark Roddy wrote:
>
>> Earlier this week on the Testing In Python list, there was a
>> discussion on how to execute a setup and/or teardown for a single test
>> class instead of for each test fixture on the class (see the 'setUp
>> and tearDown behavior' thread).  I have had to deal with situation
>> myself before, and I am obviously not the only one (since I did not
>> initiate the thread).  As such I'd like to propose adding a class
>> level setup and tear down method the unittest TestCase class.
>>
> I think that this is the wrong approach to the problem:
>   - class scope for such fixtures drives large test classes, reduces
> flexability
>

Agreed.

>   - doing it the rough way you suggest interacts in non obvious ways with
> test order randomisation
>

Not currently in unittest, so not really an issue.
>   - it also interacts with concurrent testing by having shared objects
> (classes) hold state in a way that is not introspectable by the test
> running framework.
>

Again, unittest doesn't do concurrent testing out of the box.

How are shared fixtures like this not introspectable?

As I see it.

Advantages of setupClass and teardownClass:

* Simple to implement
* Simple to explain
* A commonly requested feature
* Provided by other test frameworks in and outside of Python

Disadvantages:

* Can encourage a poor style of testing, including monolithic test classes

> I'd much much much rather see e.g. testresources integrated into the
>

How is testresources superior? Can you demonstrate this - in particular 
what is the simplest example? The simplest example of setupClass would be:

class SomeTest(unittest.TestCase):
     def setupClass(self):
         ... # setup shared fixture

> core allowing fixtures to be shared across test instances in a way that
> doesn't prohibit their use with concurrent testing, doesn't make it
> awkward to do it across multiple classes.

Can you demonstrate how testresources solves these problems.

> I'm happy to make any
> [reasonable] changes (including license) to testresources to make it
> includable in the stdlib if that's of interest.
>

That's not how contributing code to Python works. You need to provide a 
signed contributor agreement to the PSF and then you specifically 
license to the PSF any code you are contributing using one of a few 
specific licenses. For new modules in the standard library you also need 
to be willing to maintain the code.

All the best,

Michael Foord


> -Rob
>


-- 
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.