[Zope-dev] Test fixture concepts

Martin Aspeli optilude+lists at gmail.com
Mon Mar 28 17:27:25 EDT 2011


On 28 March 2011 15:45, Tres Seaver <tseaver at palladion.com> wrote:
> The vast majority of the doctest testcases in zope.* packages fall into
> this category:  poor isolation, lots of edge cases which would obscure
> any real narrative docs, of which there are almost none.  I believe the
> conflict is intrinsic, here, and not just an accident of careless /
> naive implementation:  exercising all the preconditions of the contract
> of the function-under-test makes for really poor documentation, but is
> essential to good testing.

Agree. Here's what I've found and learned the hard way:

doctests are sometimes easier / more fun to write the *first* time I
write tests. It's easy to just start writing, and the narrative helps
me think about what I'm doing. Plus, it feels like I'm saving time on
writing docs.

They are much worse all subsequent times. Maintenance becomes a soup.
Quick tests for edge cases feel like they obscure the narrative, so I
may forgo them. Refactoring is painful. Tool support is poorer, e.g.
no stepping through with pdb and no pyflakes. And people find the docs
underwhelming.

If I'm doing it wrong, I'd like to see it done "right". Manuel is kind
of cool, but I'm not sure it really addresses the issue. It's a better
doctest, not a better unittest. Most zope.component packages only get
away with simple doctests because they are simple/small packages
(which is a good thing, mainly, of course).

One of the main objections to unittest(2) seems to be that it's
"Javaesque". Yes, JUnit was the first library to solidify many of the
current, cross-language testing patterns. We shouldn't be so
NIH-stricken that we can't see the benefit of being consistent with
patterns used in most other languages and test frameworks these days.

Martin


More information about the Zope-Dev mailing list