[Zope3-Users] Re: [Zope] Debugging doctests
chrism at plope.com
Thu Feb 23 12:25:16 EST 2006
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 <gary at zope.com> 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 at zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-dev )
More information about the Zope