[TIP] cleanUp for unittest

[Michael Foord]

Olemis Lang wrote:
> On Fri, Apr 3, 2009 at 12:16 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> 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.
>>
>>     
>
> My initial position is as follows unittest is a framework inheriting
> well-known features present in many similar testing framews for many
> languages ... I think that unittest.TestCase should include nothing
> but the really simple, common and crucial features for defining test
> cases according to XUnit paradigm ... And should be kept as stable as
> possible ...
>
> Q: I'd like to know if there is another XUnit framew for another
> language providing such a functionality in core ...
>
> Q: I'd like to know how many use cases in stdlib test suite can
> benefit from this feature ...
>
> I do think this is helpful ... I dont think it should be included in
> unittest.TestCase ... you'll get a +1 from me if you do that in a
> subclass of unittest.TestCase which can be also in stdlib ...
>
> I see this more like a testing pattern ... AFAICR there's something
> like this in XUnit patterns book and still this is not in JUNit's
> TestCase class, or similar, AFAIK ...
>
> Pls ... CMIIW anyway ...
>
>   
I have no idea whether this particular feature is in other xUnit 
inspired frameworks. Irregardless, unittest is a Python testing 
framework and development should be driven by patterns useful to testing 
Python - and whether or not similar patterns are used elsewhere is 
more-or-less irrelevant. For example, you would never implement this 
feature in this way in Junit because Java has no first class functions.

Looking for examples in the standard library would be a good idea. To be 
honest it seems such a clean and simple idea I'm surprised at the 
pushback so may not pursue it. But still, plenty of other fish to fry.

I don't think that unittest itself should grow new TestCase subclasses. 
Either functionality is worth having or it isn't - no need to add 
confusion as to which version of the standard library TestCase you are 
or should be using.

Michael

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