[TIP] cleanUp for unittest

[Michael Foord]

holger krekel wrote:
> On Fri, Apr 03, 2009 at 18:32 +0100, Michael Foord wrote:
>   
>> holger krekel wrote:
>>     
>>> On Fri, Apr 03, 2009 at 18:16 +0100, Michael Foord wrote:
>>>   
>>>       
>>>> C. Titus Brown wrote:
>>>>     
>>>>         
>>>>> On Fri, Apr 03, 2009 at 06:08:58PM +0100, Michael Foord wrote:
>>>>> -> There is a feature request for unittest that we add a 'cleanUp' list.
>>>>> -> -> This is a list of functions to call on exit of a test that 
>>>>> can be added -> to in setUp or during test execution. The 
>>>>> difference between this and -> tearDown is that if anything is in 
>>>>> the cleanUp list they will be called -> *even* if setUp fails 
>>>>> (which normally means tearDown is skipped).
>>>>> -> -> Is there consensus that adding this to unittest is a good 
>>>>> thing? If -> there is then I will just do it...
>>>>> -> -> Should it be done before or after calling tearDown? I don't 
>>>>> think it -> matters so long as it is documented.
>>>>>
>>>>> Doesn't matter to me, but I'm wondering... why a list of functions?
>>>>>
>>>>> --titus
>>>>>         
>>>>>           
>>>> I should have listed the relevant issue: http://bugs.python.org/issue5538
>>>>
>>>> The idea is that as you allocate resources that need cleaning up, you 
>>>> push the corresponding clean up function onto the list. It is what 
>>>> trial uses.
>>>>
>>>> It sounds like a very simple system to me.
>>>>     
>>>>         
>>> hum, doesn't something like 
>>>
>>>     def setUp(self):
>>>         try:
>>>             ...
>>>         finally:
>>>             self.tearDown()
>>>
>>> express well enough what the poster wants to do?  Or am i missing 
>>> something? 
>>>
>>>       
>> It does but is an unacceptable solution because it changes the semantics  
>> of the current behavior.
>>
>> cleanUp is a solution that would meet his need without drastically  
>> changing the way setUp and tearDown behave.
>>     
>
> huh?  i meant the above for the user's code, not unittest.py
>   


Oops. And it would seem to meet the user's specific needs. :-)

>   
>>> I think that running teardown() only when setup() suceeded
>>> seems nice and simple.  Adding more logic to unittest.py for
>>> handling "cleanUps" in addition to "teardDown"'s and explaining
>>> how this relates sounds relatively complicated to me.    
>>>       
>> Oh well, if there isn't some semblance of consensus then it's probably  
>> not a good idea. :-)
>>     
>
> Admittedly, i am not a big user of unittest.py style tests.  
> But i became to dislike setup/teardown methods in general,
> both as used in unittest.py and as extended in py.test and nose. 
> They only provide for readable test setup and code when 
> used for small unittests (if even then). 
>   

That hasn't been my  experience, but I can understand it.

We subclass TestCase to provide various different test base classes that 
provide infrastructure (FunctionalTestCase, ServerTestCase, 
InstallerTestCase, GUIThreadTestCase for example) and make good use of 
setUp and tearDown in all of these.

I agree that setUp / tearDown are most useful when they group a 
small(-ish) number of related tests in a single class - but this is a 
nice way to use unittest anyway.

> For larger scale tests and setup of many test resources 
> setup/teardown adds a layer of indirection.  
>
> What about a more direct way of resource management:  a way to
> say "i need this XYZ resource" and a way to provide this named
> test resource.  E.g. a test function could like this:
>
>     def test_database_works_well_on_tempio(self):
>         db = self.getresource("db")
>         tempio = self.getresource("tempio")
>
> and the getresource() would lookup a provider and call it. 
> There would be no need for setUp/tearDown methods and 
> the provider could register cleanup functions.  
> This way resource usage and setup is nicely separated 
> and the test reader and writer have an easier job. 
>   


Which is fine (and dandy - nice pattern); until you have five tests that 
all use the same resources, and you stick that code in the setUp. ;-)

Your proposal already works fine with unittest (or at least is simple to 
add) - and in fact would work better with addCleanUp as each resource 
provider can add its own tearDown to the clean up stack.

Michael
> py.test uses a similarly motivated request/provider scheme 
> for small, medium and larger tests lately.  People in the 
> testing tutorial gave very posive feedback on it.  
>
> cheers,
>
> holger
>
>
>   
>> Michael
>>     
>>> just my 2cents,
>>> holger
>>>    
>>>       
>>>> Michael
>>>>
>>>> -- 
>>>> http://www.ironpythoninaction.com/
>>>> http://www.voidspace.org.uk/blog
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> testing-in-python mailing list
>>>> testing-in-python at lists.idyll.org
>>>> http://lists.idyll.org/listinfo/testing-in-python
>>>>
>>>>     
>>>>         
>>>   
>>>       
>> -- 
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>>     
>
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog