[TIP] cleanUp for unittest

[holger krekel]

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

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

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. 

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

-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu