doctest.Tester is deprecated

[Michele Simionato]

Tim Peters <tim.peters at gmail.com> wrote in message news:<mailman.2930.1094484289.5135.python-list at python.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