[FRPythoneers] Doctest

Rob Riggs rob at pangalactic.org
Wed Jul 25 21:52:34 MDT 2001

Actually, I found PyUnit to be a relatively low investment. It is far 
less involved than the intellectual work required to design even one 
reasonably complete unit test plan for a module or class of moderate 
complexity. The infrastructure is fairly light-weight, and it only takes 
copying and modifying an example once or twice to get the hang of it. 
But, more importantly, it makes it possible (even easy) to test cases 
well beyond the trivial doctest example given below.

A simple example:

    #!/usr/bin/env python
    import socket, unittest

    class SocketTest(unittest.TestCase):

        def setUp(self):
            self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

        def testConn(self):
            netAddr = ('www.lug.bouldre.co.us', 80)
            except Exception, e:

        def tearDown(self):

    if __name__ == '__main__':

        suite = unittest.TestSuite()

This seems fairly trivial to me since using PyUnit for a while. The 
setUp() and tearDown() pieces are optional, and the code in those 
functions could have been moved directly into the test case, making the 
example even shorter.

I also believe that having the unit tests in a seperate module helps one 
differentiate the task of code and the task of testing in one's mind. I 
find it easy to fool myself when writing code, but when I'm "in testing 
mode" I can see far more cases in which I can potentially break the 
code.Also, in many (most?) cases my unit tests comprise more code that 
the actual class being tested. I could not see putting that code in 
comments within the class. It would distract too much from the actual code.

I think it's cool that doctest exists, but I don't see it as a 
replacement for PyUnit.

Sean Reifschneider wrote:

>I haven't ever gotten into using PyUnit, mostly because it always seemed
>like it was too much of an investment to make to get into it.  In fact,
>I've written some of my own unit-testing routines for some of my code
>instead of using PyUnit.  For something I was working on this week I
>decided I should just bite the bullet and build some unit-tests for it.
>So I dug out the library manual entry for it and found that it really is
>kind of a high-investment thing to get into...  You have to build a bit of
>infrastructure, then you can run some methods that take a true or false and
>a string:
>   failUnless(math.floor(1.9) == 1.0, 'Floor failed!')
>I haven't checked it, but that smells like it's not actually going to give
>you data about what was produced and what was expected, which was really
>all I wanted.
>I ran across doctest and it's VERY sweet.  For example, imagine that you
>have a module file called "dt.py" with the following in it:
>   #!/usr/bin/env python2
>   #
>   #  Copyright (c) 2001, Sean Reifschneider, tummy.com, ltd.
>   #  All Rights Reserved.
>   revision = '$Revision$'
>   rcsid = '$Id$'
>   def mult(x, y):
>      '''Multiply the first argument with the second.
>      Example:
>         >>> mult(1, 2)
>         2
>         >>> mult(2, 4)
>         8
>         >>> mult(9, 9)
>         81
>         >>> mult(0, 100)
>         100
>      '''
>      return(x * y)
>   ##########################
>   if __name__ == '__main__':
>      import doctest, dt
>      doctest.testmod(dt)
>In this case, if you run the module stand-alone, it will pull the example
>section out of the docstring, and run it, reporting if the results don't
>match what it expected:
>   guin:tarcmp$ python2 dt.py
>   *****************************************************************
>   Failure in example: mult(0, 100)
>   from line #10 of dt.mult
>   Expected: 100
>   Got: 0
>   *****************************************************************
>   1 items had failures:
>      1 of   4 in dt.mult
>   ***Test Failed*** 1 failures.

More information about the FRPythoneers mailing list