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 <gary@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@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 )