RFC: Additional functionality for PyUnit

Barry A. Warsaw barry at zope.com
Wed Aug 29 15:58:20 EDT 2001


>>>>> "M" == MikeK  <mkent at atlantic.net> writes:

    M> Well, my post generated a big yawn, but since I just now ran
    M> into a situation that's a good example of why I would like
    M> PyUnit to be enhanced a bit, I thought I'd share it.

I definitely missed your first posting, because my python-list reading
is spotty at best, but...

    >> Here's a proposed change to unittest.py that I'd like your
    >> comments on.  I've found unit testing with PyUnit to be
    >> invaluable.  I've gotten to the point where writing any Python
    >> code without unit tests seems, well, perverse.  :) But there's
    >> an inadequacy in PyUnit I keep running into that I'd like
    >> addressed.  I often work with code that requires a large amount
    >> of work to set up a test for, and the setup code takes an
    >> appreciable amount of time to run.  Often, several tests that
    >> are grouped into a test case all require a common setup.  Now,
    >> PyUnit provides us with setUp() and tearDown() methods that we
    >> can define for each test case, which is good.  The setup()
    >> method is run prior to EACH test method of a test case, and the
    >> tearDown() method is run after EACH test method of a test case.
    >> However, when you have several test methods defined in a test
    >> case, that all need a common setup for the tests, and the setup
    >> is both work and time intensive, what you really want is to
    >> have a different and additional set of setup and teardown code
    >> that is only run ONCE for the test case.  This would let me run
    >> the difficult and long-running setup for a series of related
    >> tests once.  It would really make unit testing my code more
    >> doable.

I have also wanted something like this, for much the same reasons.  A
(long) while back (and sorry, I don't remember in which forum), I made
the suggestion that TestSuites should have setUp() and tearDown()
methods.  That would probably do what you want, while improving the
polymorphism of the test classes.

-Barry




More information about the Python-list mailing list