467,859 Members | 1,360 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,859 developers. It's quick & easy.

doctest.Tester is deprecated

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
  • viewed: 1437
Share:
2 Replies
[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
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.

Similar topics

14 posts views Thread by Pierre Rouleau | last post: by
3 posts views Thread by Edward K. Ream | last post: by
2 posts views Thread by Alan G Isaac | last post: by
5 posts views Thread by Michele Simionato | last post: by
1 post views Thread by Runsun Pan | last post: by
24 posts views Thread by john_sips_tea | last post: by
reply views Thread by Eric Mahurin | last post: by
12 posts views Thread by thomas.guest | last post: by
6 posts views Thread by Bzyczek | last post: by
reply views Thread by jack112 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.