On 28 March 2011 15:45, Tres Seaver <tsea...@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
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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -