[TIP] cleanUp for unittest

Michael Foord fuzzyman at voidspace.org.uk
Fri Apr 3 10:32:38 PDT 2009


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

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





More information about the testing-in-python mailing list