[Python-Dev] setUpClass and setUpModule in unittest

[Michael Foord]

On 11/02/2010 12:30, Nick Coghlan wrote:
> Michael Foord wrote:
>    
>> I'm not sure what response I expect from this email, and neither option
>> will be implemented without further discussion - possibly at the PyCon
>> sprints - but I thought I would make it clear what the possible
>> directions are.
>>      
> I'll repeat what I said in the python-ideas thread [1]: with the advent
> of PEP 343 and context managers, I see any further extension of the
> JUnit inspired setUp/tearDown nomenclature as an undesirable direction
> for Python to take.
>
> Instead, I believe unittest should be adjusted to allow appropriate
> definition of context managers that take effect at the level of the test
> module, test class and each individual test.
>
> For example, given the following method definitions in unittest.TestCase
> for backwards compatibility:
>
>    def __enter__(self):
>      self.setUp()
>
>    def __exit__(self, *args):
>      self.tearDown()
>
> The test framework might promise to do the following for each test:
>
>    with get_module_cm(test_instance): # However identified
>      with get_class_cm(test_instance): # However identified
>        with test_instance: # **
>          test_instance.test_method()
>    

Well that is *effectively* how they would work (the semantics) but I 
don't see how that would fit with the design of unittest to make them 
work *specifically* like that - especially not if we are to remain 
compatible with existing unittest extensions.

If you can come up with a concrete proposal of how to do this then I'm 
happy to listen. I'm not saying it is impossible, but it isn't 
immediately obvious. I don't see any advantage of just using context 
managers for the sake of it and definitely not at the cost of backwards 
incompatibility.

Michael
> It would then be up to the design of the module and class context
> manager instances to cache any desired common state. Further design work
> would also be needed on the underlying API for identifying the module
> and class context managers given only the test instance to work with.
>
> The get_*_cm mechanisms would return a no-op CM if there was no specific
> CM defined for the supplied TestCase.
>
> Cheers,
> Nick.
>
> [1]
> http://mail.python.org/pipermail/python-ideas/2010-January/006758.html
>
>
>    


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