doctest.Tester is deprecated

  • Thread starter Michele Simionato
  • Start date
M

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?


Michele Simionato
 
T

Tim Peters

[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.
42
--- b.txt ---------------------------------------------------
And so is this.
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.
 
M

Michele Simionato

Tim Peters said:
[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.
42
--- b.txt ---------------------------------------------------
And so is this.
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

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top