[Zope3-Users] Re: [Zope] Debugging doctests

[Chris McDonough]

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