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 -- http://mail.python.org/mailman/listinfo/python-list
