[TIP] Fwd: cleanUp for unittest

Michael Foord fuzzyman at voidspace.org.uk
Fri Apr 3 13:25:15 PDT 2009


Olemis Lang wrote:
> On Fri, Apr 3, 2009 at 3:01 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>   
>> Olemis Lang wrote:
>>     
>>> On Fri, Apr 3, 2009 at 2:14 PM, Fred Drake <fdrake at gmail.com> wrote:
>>>
>>>       
>>>> The zope.testing package provides a setupstack module that provides
>>>> support for this (though with the clunky constraint that the cleanup
>>>> function that calls the stacked cleanups has to be arranged for).
>>>>
>>>> Having a way to support this functional behavior as part of the
>>>> standard TestCase class would be a substantial improvement over the
>>>> current situation.  There should be a method to add a cleanup function
>>>> and another to call them at the end as part of the base
>>>> implementation.
>>>>
>>>>
>>>>         
>>> Dont understand ? Why not to do it completely in a TestCase subclass
>>> for the basic testing stack and another for your specific features ?
>>>
>>> I dont see why this *CANT* be done outside TestCase ... and neither
>>> why it *SHOULD* be done there ...
>>>
>>>       
>> The fact that three major projects all have similar implementations to
>> provide this  functionality is a good indicator that it is something that
>> should be provided by the framework. Because of the way unittest works the
>> implementation of this particular feature is fiddly - you need to override
>> run - and there are genuine  use cases.
>>
>> The implementation and usage is all clean and straightforward to understand,
>> which again are points in its favour. Resource allocation / deallocation is
>> something that it is easy to get wrong in testing, this makes it easier.
>>
>>     
>
> Sometimes I think I dont make myself clear ... if they inside unittest
> pkg or mdl I'll give you a big +100 ^ 2 ... if they are part of
> TestCase I give a -1 ...
>
> Perhaps what is needed is to refactor unittest.TestCase.run method so
> that other frameworks can extended more easily ... and this is
> something I've being thinking since a long time ago ... when I
> implemented dutest ...
>
>   

It might be worth communicating with Barry Warsaw about this as he is 
interested in similar sounding features for doctest.

Eventually we would like to add a common test collection / running 
mechanism to doctest and unittest so that a single project can run all 
its tests from a very simple API. Sounds similar to dutest.

> ... which in fact had a similar «big problem» to solve ... change
> doctest monolithic, file-oriented reporting interface to report every
> single match made for doctests using the completely different
> interface provided by instances of TestResult ... implementation is a
> bit hacky ... since doctest is in the middle ... but usage is smooth
> ..
>
> Results : It has been done without modifying neither doctest nor unittest ...
>
> Non-invasive procedures are always better ... ;)
>   

Well, on the feature under discussion Zope, Twisted and Bzr have all 
provided it without modifying TestCase but have had to write a lot more 
code as a result...

Michael

> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
>
>
>   


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





More information about the testing-in-python mailing list