Additional functionality for PyUnit

John Roth johnroth at ameritech.net
Mon Aug 20 02:08:40 EDT 2001


"MikeK" <mkent at atlantic.net> wrote in message
news:efd753ca.0108180619.111f10d1 at posting.google.com...
> 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.

PyUnit isn't magic. For example, it doesn't force your modules to be
recompiled for each test, and it doesn't reimport them, either. If you
really
have to have a setup for a group of unit tests, it's easy enough to do -
just
save a reference to the necessary objects at the module level somewhere.

The instance of your test class will vanish, but whatever setup you need to
keep will remain referenced, and hence, available.

John





More information about the Python-list mailing list