doctest.Tester is deprecated

Tim Peters tim.peters at gmail.com
Mon Sep 6 11:24:47 EDT 2004


[Michele Simionato]
> Some time ago I hacked a custom solution to run doctests
> on text files containing documentation. The solution
> involved this kind of game:
>
> tester=doctest.Tester(globs={},verbose=1)
> tester.runstring(mytest)
>
> It worked fine, but now with Python 2.4.a3 I get
>
> DeprecationWarning: class Tester is deprecated; use class
> doctest.DocTestRunner instead
>
> The problem is that DocTestRunner is not a replacement for Tester, it
> has no runstring method!
>
> So, how what am I supposed to do?

In the worst case, I suppose you could copy the Tester implementation
from 2.4 and maintain it yourself,  In the meantime, Tester is still
there.

But I'd encourage you to think about better approaches.  Most people
are using unittest to *drive* their test strategies, because it's
simply a much better (than doctest) framework for stitching together
many tests of various kinds from various places.

So the total refactoring of doctest for 2.4 gave up on doctest's
feeble "stitch tests together" gimmicks, and focused instead on better
support for playing with unittest.  The latter is what the people who
*contribute* to doctest use, so that's what gets loving attention.

You didn't say enough to guess whether this is appropriate, but the
new-in-2.4 doctest.DocFileSuite() creates a unittest suite directly
from one or more paths to text files containing doctests.  For
example,

--- a.txt ---------------------------------------------------
This is a text file containing doctests.

>>> print 3*14
42
--- b.txt ---------------------------------------------------
And so is this.

>>> print 42
24
--- temp.py --------------------------------------------------
import doctest, unittest
suite = doctest.DocFileSuite('a.txt', 'b.txt')
unittest.TextTestRunner().run(suite)


That built a simple unittest driver from scratch.  It does the usual
unittest business of printing a dot for each test it runs (etc), and
displays the failure, identifying file path and line number in a
useful way (e.g., Emacs can parse the "File" line, and jump directly
to the failing example):

File "b.txt", line 3, in b.txt
Failed example:
    print 42
Expected:
    24
Got:
    42

Of course you get to exploit all the rest of unittest's features this way too.

If you want to roll your own and avoid unittest, you can stitch it
together out of the new DocTestRunner and DocTestParser classes. 
That's what Tester.runstring() does in 2.4.  Note that doctest no
longer makes any use of Tester -- it's there solely for backward
compatibility.

Unfortunately, a lot of new stuff isn't yet covered in the LaTeX docs.



More information about the Python-list mailing list