[TIP] Fwd: cleanUp for unittest

Olemis Lang olemis at gmail.com
Fri Apr 3 13:30:15 PDT 2009


On Fri, Apr 3, 2009 at 3:25 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> 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...
>

Ok good point ... according to my experience (I have faced the same
problem ... I know how it feels ... ;) ... Have you already identified
that the problem they want to solve cannot be solved by refatoring a
little unittest.TestCase.run method ???

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?



More information about the testing-in-python mailing list