Thanks for the info, I’ll give a shot

I use IPython. It solves quite some problems:

• allows for pasting doctests and evaluating them (IPython.dtutils.idoctest), optionally

• raising a exception on the first failure

• doing a post-mortem pdb automatically

• executing the doctest in a separate namespace

• switching to a “normal” prompt (ipython normally has a fancy, colored, history-enabled prompt), so you can paste code from the interpreter to a doctest. One might consider this not a new feature, because the standard interpreter has this too :P

Btw, you can invoke a IPython-enabled pdb by using http://pypi.python.org/pypi/ipdb and:

from ipdb import settrace; settrace()

I like IPython :)

Stefan.

Me too, which is why I put them in setup.cfg and/or ~/.noserc:

[nosetests]
with-doctest=1
doctest-extension=.txt

“see http://www.gawel.org/weblog/2008/07/nose-doctest-plugin-sucks … I think Nose could be enhanced there.”

Unfortunately, I don’t speak French, so I’m only guessing that the post there is complaining about the lack of support in the doctest plugin for fixtures. If that’s the case, some support is scheduled for the next nose release:

http://code.google.com/p/python-nose/issues/detail?id=60

You can find the current state of fixture support in the ticket-93 branch in nose’s svn. If you find it still too sucky, patches are always welcome.

>>> import pdb; pdb.set_trace(); foo()

And once you step out of foo(), you can still step through the doctest, but stupidly you can’t see what line you’re on. This sucks.

• Stuff like pdb.set_trace() is good, but it’s better when you can do it when the test fails (what zope.testing and nose can do with options). Interaction isn’t part of the test, it’s part of the testing process.

• Something I forgot to mention: REPORT_UDIFF also has this problem. You have to put the option into the test to see the diff’d output, but it’s really part of the testing process, something you apply when you can’t quickly see the differences in output.

• REPORT_ONLY_FIRST doesn’t work: it still runs all the other examples, it just doesn’t report them. This is often fine, but sometimes I really want to abort the test. A common example would be a database-oriented set of tests, when I can’t open the database connection. Sometimes when testing destructive file operations it’s actually dangerous to continue the test if you can’t confirm that you are in a safe scratch area.

[1] https://launchpad.net/zope.testing

Yes that is a problem, the nose plugin is not really handy. We ended up faking regular test cases to be able to run our .txt doctests easily with Nose.

see http://www.gawel.org/weblog/2008/07/nose-doctest-plugin-sucks for an example of such a script.

I think Nose could be enhanced there.

“There’s no way to abort the doctest. Sometimes I’d like to run some environment checks early on, and be able to stop the test if they fail.”

You could do a simple assert on your test, with the REPORT_ONLY_FIRST_FAILURE flag on. The assert can be wrapped in a global function you provide in the test environment.