[TIP] cleanUp for unittest

[Olemis Lang]

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

Perhaps you are right about this ... but still I think that this is a
more elaborate pattern ... if it is identified as such, well there is
a good reason for leaving it out of unittest.TestCase ... for example
... this implies including other things which are not central to
seting up a test scenario ... appealing to the broad scenario ...

This is only for the case when resources (or similar artifacts ...)
are allocated for testing ...

> For example, you would never implement this feature in this way
> in Junit because Java has no first class functions.
>

Why not ... Java could include listeners which are notified of this,
and Java has anonymous classes ... which I use almost every day to
specify event handlers for e.g. Swing ... so I think this is not a
fact as you may think ... ;)

... but I've seen nothing like this in XUnit frameworks ...

For example other useful use cases really included in XUnit framews are :

- Test decorators ...
- Warning support for test cases ... and even in this case AFAIK they
are implemented usig Test Decorators ... e.g. this is the way I did it
for the test suite of the FLiOOPS project ...

I think we should have more of these instead of modifying
unittest.TestCase for this feature ... this is IMHO ... Perhaps there
is a *better* (... this is IMO ;) non invasive solution using
subclasses and|or test decorators or something else outside TestCase
class ...

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

Perhaps not, unless they are really needed ... TestDecorators are
really needed ... they have been included in JUnit 4 ... or whatever
version it is ... dont remember now ...

> Either functionality is worth having or it isn't -

XUnit is all about patterns ... so you can add a class if it is so
relevant that many (I mean many e.g. test decorators ... ;) others can
benefict of it for non-specific purposes (e.g. test decorators ...
which by itself is a dummy class ... adds no particular behavior to
solve a particular situation, but more abstract behavior to allow
writing better test cases ... ;)

> no need to add confusion
> as to which version of the standard library TestCase you are or should be
> using.
>

... if I understood well, that's one of the reasons why I dont think
TestCase should be modified ... users already know what it do, and it
does so well ... if you want it to do something else make it explicit
... write a separate subclass and do what you want ... if this is
useful enough, ok, let's make it standard ... put it in stdlib ... ;)

--
Regards,

Olemis.

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

Featured article:
No me gustan los templates de Django ...

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