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 )


_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to