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

Zope3-users mailing list

Reply via email to