doctest or pyunit?

Tim Peters tim.one at home.com
Wed May 2 17:58:25 EDT 2001


[Bruce Edge]
> What's everyone using for regression tests?
> Either of these, or a combination of both?

I mostly use doctest, but I'm its author so I have to <wink>.  I'm starting
to use pyunit just how to see how it goes.  So far it's a mixed bag.  For
example, last night I wrote

        self.assertRaises(TypeError, filter, None, 42)

in some artificial test_xxx() method of some artificial unittest.TestCase
subclass, and couldn't help yearning for the doctest way to spell that:

"""
Note that filter()'s second argument must support iteration:

    >>> filter(None, 42)
    ...
    TypeError: iter() of non-sequence
"""

So for *simple* things, unittest puts a lot of artificial constructs between
what you're trying to test and getting it tested.  OTOH, tests that require
repeated setup and teardown get real tedious real fast to write in doctest
format:  since doctest is WYSIWYG, you have to show every step of every test
explicitly in the string.  On the third hand, when a doctest test does fail,
you *do* have every step staring you in the face explicitly, so it seems
easier to me so far to track down a doctest test failure (in unittest you
blow up "somewhere" in a maze of testing classes that generally don't have
anything directly to do with the code you're testing).  On the fourth hand,
let's look at your question:

> Is doctest going to be updated to use 2.1's method attributes
> rather than the doc string?

Not while I'm alive.  doctest's primary purpose is to guarantee that examples
in docstrings work exactly as advertised.  Building tests on top of it that
*don't* serve a legitimate doc purpose is possible but a freebie that wasn't
especially intended.  The special module __test__ attribute was a late
addition in doctest's life, to provide minimal support for running doctest
tests that don't serve doc purposes.  I think also looking for
function.__test__ attributes may be a good *addition*, but before getting
around to adding that I may decide that unittest is a better approach for
fancy stuff.

when-doctest-suffices-i'm-not-sure-it's-possible-to-do-it-easier-
    but-it-doesn't-always-suffice-ly y'rs  - tim





More information about the Python-list mailing list