[TIP] Fwd: cleanUp for unittest

Olemis Lang olemis at gmail.com
Fri Apr 3 13:14:10 PDT 2009


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

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

--
Regards,

Olemis.

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

Featured article:



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