[TIP] Doctest or unitest?
benji at benjiyork.com
Wed Mar 7 06:58:04 PST 2007
Michael Foord wrote:
> If you had lots of nasty edge case testing which didn't fit well into
> documentation then I guess you could put it into a separate file.
Either a separate file, or if there aren't too many, footnotes. (I added
an extension to doctest to recognize ReST footnotes and execute them at
the point of reference instead of at the point of definition. They're
good for getting corner cases and repeated setup code out of the
narrative flow of the document).
> Isn't typing '...' all the time annoying ? (or do you code first, test
> later... ? ;-)
I try to not use ellipsis myself. We generally now use something called
the "ReNormalizer" that lets you create regular expressions that replace
matches with dummy values for those sorts of things. For example, if
you wanted to look at the repr of something and had to deal with the
object's ID changing with each run, with ellipsis you'd do this:
<Foo object at ...>
With the ReNormalizer you could make a substitution that replaces all
the addresses with something that looks like an address, but doesn't
vary and your test would just look like this:
<Foo object at 0x12345678>
That way a reader's internal Python-output-parser would still be happy
but the example test would remain deterministic.
> Don't you also lose the help of the IDE with indentation and
> autocomplete because you are no longer writing the tests in Python files ?
No one I know uses an IDE :)
That being said, I personally use a very simple Vim mode that recognizes
Python code in a doctest and highlights/completes/whatever
appropriately. I would assume that's pretty easy to do in other
> We are writing an application (rather than a library), and so don't
> *want* to document all of our internal classes / modules - so
> documentation driven design has little to offer us for these tasks. (and
> so the idea of using doctests becomes even weirder.)
I can't agree there, but don't want to burden you with a long, wandering
argument that I don't have time to make into a short, compelling one. :)
> For our acceptance (functional) tests it might be quite a nice way of
> doing them - we'd have to make our automation API look even more like a
> DSL though for it to be readable.
That was exactly the motivation for testbrowser (a testing focused,
programmatic web user agent). We had a way of doing functional tests,
but the experience of reading the tests was very different from the
experience of a user interacting with the app. If our experience with
testbrowser is any indication, developing a good test API for your app
will go a long way to making testing easier and also help find more bugs.
More information about the testing-in-python