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

[Michael Foord]

On 21/01/2010 04:03, Robert Collins wrote:
> On Wed, 2010-01-20 at 22:32 -0500, Mark Roddy wrote:
>
>    
>>> I think that this is the wrong approach to the problem:
>>>   - class scope for such fixtures drives large test classes, reduces
>>> flexability
>>>        
>    
>> I can see how this could arise, but it has not been my experience (I
>> have a class setup system I've been using for a little while).  A
>> setUp method alone can be abused to create large inflexible tests.  I
>> think the answer to this is good documentation that clearly states
>> that abusing the functionality can lead to shooting oneself in the
>> foot.
>>      
> Yes, setUp and tearDown can be problematic as well. Junit which has has
> setUp and setUpClass a long time has recently
> (http://kentbeck.github.com/junit/doc/ReleaseNotes4.7.html) added a
> system called Rules which is similar to testresources (though the fine
> detail is different). The key elements are the same though:
>   - rules are their own hierarchy
>   - rules are added to tests not part of the test specific code
>   - framework takes care of bringing up and taking down rules.
>    

Right, they *can* be problematic but they can also be extremely useful 
if not abused. My feeling is that the same is true of setupClass and 
teardownClass.

Replacing them with a more complex mechanism is not necessarily a win, 
although a more complex mechanism for more complex use cases is 
justified (although it doesn't necessarily *need* to be in the standard 
library).

> [snip...]
>>> I'd much much much rather see e.g. testresources integrated into the
>>> 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. I'm happy to make any
>>> [reasonable] changes (including license) to testresources to make it
>>> includable in the stdlib if that's of interest.
>>>        
>    
>> A pretty good approach for a complicated setup, but in a simple case
>> where you only need a line or two it seems like a lot of boiler plate
>> to get the job done.  Though I'll look into this library a little more
>> as I am not intimately familiar with it at the moment.
>>      
> If you only need a line or two, its hard to justify setUpClass being
> used :).
>
> Anyhow, its really not much boilerplate:
> class MyResource(TestResource):
>      def make(self, deps):
>          # line or two
>          return thing
>
> I am considering adding a helper to testresources:
>
> def simple_resource(maker, cleaner):
>      class MyResource(TestResource):
>          def make(self, deps):
>              return maker(deps)
>          def clean(self, resource):
>              cleaner(resource)
>      return MyResource
>
> which would make the boilerplate smaller still.
>    

This doesn't show how testresources is used in conjunction with unittest 
- can you give a minimal *self contained* example please.

Thanks

Michael

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