[Python-Dev] setUpClass and setUpModule in unittest

Michael Foord fuzzyman at voidspace.org.uk
Tue Feb 9 23:42:39 CET 2010


On 09/02/2010 21:57, Ben Finney 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.
>    

I've used unittest for long running functional and integration tests (in 
both desktop and web applications). The infrastructure it provides is 
great for this. Don't get hung up on the fact that it is called 
unittest. In fact for many users the biggest reason it isn't suitable 
for tests like these is the lack of shared fixture support - which is 
why the other Python test frameworks provide them and we are going to 
bring it into unittest.

Michael

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


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