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.
- C
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
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
