[Python-Dev] unittest2 plus class and module level fixtures in unittest

Michael Foord fuzzyman at voidspace.org.uk
Mon Mar 8 20:20:50 CET 2010


On 08/03/2010 01:11, Antoine Pitrou wrote:
> Le Mon, 08 Mar 2010 00:51:02 +0000,
> Michael Foord<fuzzyman at voidspace.org.uk>  a écrit :
>    
>> In other news, class and module fixtures (setUpClass /
>> tearDownClass / setUpModule / tearDownModule) are now implemented in
>> unittest (in trunk
>> - not yet merged to py3k). These features are tested but I'm sure
>> there are some lurking bugs or oddities, so please try them out. I
>> have not yet added documentation for them; I'll pull it out from this
>> email as a starting point.
>>
>> I'd rather this thread didn't become *another* debate on the merit of
>> these features, but perhaps that is too much to hope for.
>>      
> Just for the record, could you sum up the reasons why you/we decided on
> this route rather than e.g. adding a test-resources-like facility?
>
> (I'm not saying I disagree, it's just that I didn't remember a decision
> had already been made on this point)
>    

Well, Guido had already stated on python-ideas that he wanted these 
features (class and module fixtures) in unittest. I (and others) 
suggested testresources as an alternative but it became clear that it 
didn't offer a suitable abstraction for module level fixtures, instead 
you would have to manually attach the resources to all of the classes in 
the module yourself.

In addition to the lack of a module level fixture abstraction Guido felt 
that the testresources API itself was not yet mature or polished enough 
to come into the standard library. At that point I figured we had 
reverted to the decision that setUpClass / setUpModule should go in.

testresources still works of course, and is a better general solution 
for shared fixtures where people are pushing beyond what setUpClass and 
setUpModule allow. I'll probably link to testresources in the shared 
fixture documentation - and it has the great advantage of *not* being in 
the standard library and is therefore free to evolve faster.

All the best,

Michael

> Thanks for all your work on this!
>
> cheers
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>    


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