I dunno about sucking because they are quite good for documentation,
but I tend to write plain-old unittests instead of doctests when I'm
testing without any pretense towards writing documentation. If you
test internals of a class in a doctest, the doctest body gets pretty
cluttered, which tends to defeat the documentation-esque-ness of them.
Being able to set a breakpoint in the test body is important for me
too. I probably could be setting breakpoints once I'm in the
debugger, but it's often easier to just stuff in a pdb.set_trace()
before the line of code that I want to examine. And putting a set
trace in a unittest is a natural thing to do, because you know the
set trace will only get invoked once during a test run (as opposed to
putting it right in the app code, where it might get invoked "by
accident" through a different test). Setting breakpoints in unittest-
tests is typically more fruitful than putting them in doctest-tests
for the reasons that have been talked about in this thread.
On Feb 23, 2006, at 11:27 AM, Lennart Regebro wrote:
On 2/23/06, Gary Poster <[EMAIL PROTECTED]> wrote:
You effectively can't step through all the tests (with a single
pdb). You can step through a single line in the test well. While it
sounds limiting, that has proved quite sufficient for me in
practice. YMMV, of course.
Sigh. doctests really do suck.
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -
Zope3-users mailing list