Art of Unit Testing

[Christoph Zwerschke]

Peter Hansen wrote:
> What's wrong with using Python's existing "global" support, and just 
> having your test case setUp() call a global setup routine which checks 
> whether that global setup work has already been done and, if not, does 
> it once and sets a flag to say that it has now been done?  I've done 
> this easily in the few cases where I've wanted this behaviour.  It 
> doesn't seem complex enough to warrant adding to the standard unit test 
> support.

Actually I already thought about doing it that way, but then I thought 
it is so ugly, there must be a simpler solution ;-)

> If you're going to quote XP rules of thumb, the tests should be 
> independent and very fast, and if you have a setup code that is taking a 
> long time, it's likely a "code smell" of some kind, and you should be 
> fixing the design which prevents you writing these tests with minimal 
> and quick setup.  Are these really like "acceptance" tests?  If they 
> were unit tests, they should take only a few minutes to run, total, and 
> you should be running them all *many* times a day, not twice.

You're right. I think wanting to have a more global initialization 
indicates that you are acutally not wanting to do a "unit" test, but a 
more global test of the overall system, something like an acceptance or 
integration test, i.e. you are trying to abuse unittest for something it 
was not intended to be used for.

Maybe since unittest is the only testing framework included with the 
standard lib, people tend to use it for all testing purposes. If you 
only have a hammer, everything looks like a nail.

-- Christoph