[TIP] cleanUp for unittest

Scott David Daniels Scott.Daniels at Acm.Org
Sat Apr 4 10:24:36 PDT 2009


Sorry, this is a reply to several things.

Holger Krekel:
 > Admittedly, i am not a big user of unittest.py style tests. 
 > But i became to dislike setup/teardown methods in general,
 > both as used in unittest.py and as extended in py.test and nose.
 > They only provide for readable test setup and code when
 > used for small unittests (if even then).
 > For larger scale tests and setup of many test resources
 > setup/teardown adds a layer of indirection. 
Specifically, you obviously don't do tests whose setup begins
something like:
    ...
    turn on the heaters
    ...
    turn on the electronics
    ...
    initialize the hardware
    ...
    <actually do the setup of the test situation>

Once we had power on, we'd appreciate certainty we turn it
off to avoid fire hazards.  The stack has the lovely property
of insuring safety.  Of course we never ran these tests
unattended, but it is not a good idea to rely solely on an
operator noticing a problem and hitting the big red button.

Doug Philips asks:
 > I think having this an tearDown is a recipe for confusion.
 > Can you explain how this interacts with tearDown, specifically,
 > if I have this, why would I ever put anything into tearDown?

Much of a tearDown can be done regardless of the machine's normal
state, because you can depend on the machine being properly
initialized.  Tests may do things that have to be undone, but
sometimes they move past those to get back to a simple state.
Those undos don't belong on the stack.

Jonathan Lange comments:
 > I tried adding it to Python but became embroiled in a controversy
 > similar to this one.
 > The signature is:
 >    def addCleanup(self, function, *args, **kwargs):
 >        ...
I personally like this a lot.  Easy on the eyes when reading the tests.

--Scott David Daniels
Scott.Daniels at Acm.Org




More information about the testing-in-python mailing list