Art of Unit Testing

[Raymond Hettinger]

Christoph Zwerschke wrote:
> I wasn't aware of the py lib so far. The
> possibility to create fixtures at the three different scopes is exactly
> what I was looking for.
>
> Anyway, I think it would be nice to have that feature in the standard
> lib unittest as well. It should not be too hard to add setUpOnce and
> tearDownOnce methods in addition to setUp and tearDown. Actually, I am
> wondering that there doesn't seem to be any development progress since
> unittest was included in the standard lib of Python 2.1 in August 2001.
> I had expected that such an important module would be continually
> improved and maintained. How come? So few people using unit tests? Or do
> most people write their own testing code or use py.test?



Voice of Mr. Unittest: """
The details of the implementation are not nearly as important as the
test cases.  If you can support a set of test cases like the ones given
here, then you can write tests that are isolated and can be composed,
and you will be on your way to being able to develop test-first.
 . . .
The spirit of xUnit is simplicity.
 . . .
Some of the implementations have gotten a little complicated for my
taste. """ -- Kent Beck, Test Driven Development, p. 119.

Python's unittest module is already a bit to complicated.  Building it
out further would be a step in the wrong direction.  As it stands now,
it is somewhat powerful and flexible without being overly difficult to
learn.

FWIW, it does not take much skill to use the existing unittest module
to meet advanced testing needs.  Lib/test/test_decimal.py has few lines
that dynamically build a whole suite of tests from a directory of text
resource files.  Lib/test/test_compiler.py has just a few lines to
shorten testing time by running a random subset of tests.
Lib/test/test_deque.py has a handful of lines to run the suite multiple
times to check reference counts and it incorporates a doctest suite to
verify the examples in the documentation.

Your own feature request for setUpOnce() and tearDownOnce() is
trivially coded using a global or class variable to restrict running to
a single occasion.  If that seems unpleasant, then encapsulate the
logic in a subclass of TestCase, in a decorator, or in a metaclass.

If you want better, try py lib's py.test module which is both more
minimalistic and more powerful.



Raymond


P.S.  The above is based on the experience of writing thousands of
lines of test code.  The existing unittest module is just fine without
further buildout.  If it weren't for backwards compatibility issues, I
would recommend pairing it down further -- only a small subset of its
features are necessary to meet most needs.