By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,780 Members | 1,520 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,780 IT Pros & Developers. It's quick & easy.

doctest.Tester is deprecated

P: n/a
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?
Michele Simionato
Jul 18 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
[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.
Jul 18 '05 #2

P: n/a
Tim Peters <ti********@gmail.com> wrote in message news:<ma**************************************@pyt hon.org>...
[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.

Ah! DocFileSuite is *exactly* what I want, I used Tester to implement it
by hand (of course, in a more primitive way). My confusion was with the
DeprecationWarning: class Tester is deprecated; use class
doctest.DocTestRunner instead


It could say

"use class doctest.DocTestRunner or doctest.DocFileSuite instead"

Of course the better solution would be to have the documentation finished ;)

BTW, I am convinced user of doctests since I feel them simpler, more readable
and expecially more maintanable than unittests. Moreover they feel to me
more "pythonic" than unittest, that certainly reflect their Smalltalk/Java
origin.

I welcome these new additions to doctest. I hurry to try them! ;)
Michele Simionato
Jul 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.