- Doctest
doctest is a module included in the Python programming language's standard library that allows the easy generation of tests based on output from the standard Python interpreter shell, cut and pasted into docstrings.
Implementation specifics
doctest makes innovative use of the following Python capabilities:
* docstrings
* The Python interactive shell, (both command line and the included idle application).
* Python introspectionWhen using the Python shell, the primary prompt: >>> , is followed by new commands. The secondary prompt: ... , is used when continuing commands on multiple lines; and the result of executing the command is expected on following lines.A blank line, or another line starting with the primary prompt is seen as the end of the output from the command.
The doctest module looks for such sequences of prompts in a docstring, re-executes the extracted command and checks the output against the output of the command given in the docstrings test example.
The default action when running doctests is for no output to be shown when tests pass. This can be modified by options to the doctest runner. In addition, doctest has been integrated with the Python unit test module allowing doctests to be run as standard unittest testcases. Unittest testcase runners allow more options when running tests such as the reporting of test statistics such as tests passed, and failed.
Literate Programming and Doctests
Although doctest does not allow a Python program to be embedded in narrative text, they do allow for verifiable examples to be embedded in docstrings, where the docstrings can contain other text. Docstrings can in turn be extracted from program files to generate documentation in other formats such as HTML or PDF. A program file can be made to contain the documentation, tests, as well as the code and the tests easily verified against the code. This allows code, tests, and documentation to evolve together.
Documenting libraries by example
Doctests are well suited to provide an introduction to a library by demonstrating how the API is used.
On the basis of the output of Python's interactive interpreter, text can be mixed with tests that exercise the library, showing expected results.
Examples
Example one shows how narrative text can be interspersed with testable examples in a docstring. In the second example, more features of doctest are shown, together with their explanation. Example three is set up to run all doctests in a file when the file is run, but when imported as a module, the tests will not be run.
Example 1: A doctest embedded in the docstring of a function
Example 2: doctests embedded in a README.txt file
Demonstration doctests
This is just an example of what a README text looks like that can be used withthe doctest.DocFileSuite() function from Python's doctest module.
Normally, the README file would explain the API of the module, like this:
>>> a = 1 >>> b = 2 >>> a + b 3
Notice, that we just demonstrated how to add two numbers in Python, and what the result will look like.
A special option allows you to be somewhat fuzzy about your examples:
>>> o = object() >>> o # doctest: +ELLIPSIS
Example 3: unique_words.py
This example also simulates input to the function from a file by using the python [http://docs.python.org/lib/module-StringIO.html StringIO] module
Critique of doctest
Advantages
* Many programmers already use the Python shell to test their code. Cutting and pasting from the shell to a docstring is a very simple way of generating tests.
* Tests and code are together. The tests are easily run making them much more likely to be kept up-to-date.
* Some level of documentation, tests and code are kept together.
* Testing of exceptions looks very intuitive.
* A simple concept.
* Can test for returned exceptions
* Nice output formatting/comparison integration (e.g. whitespace normalization, ndiff usage for failed examples, use of ellipsis).Disadvantages
* Large numbers of tests in a docstring can become unwieldy. docstrings should be pruned and excised tests put in external file(s).
* Tests producing large amounts of output make for large docstrings.
* Debugging integration is far from perfect.
* 'print' (or 'trace') debugging is not possible (because it intervenes with the test result).
* Test setup has to be either copied or hidden away from the test, making the overall environment harder to understand.
* A few of the complex assertions of other unit test frameworks do not exist, (e.g. assert_almost_equal).
* Failing assertions can be harder to debug if you compare a lot of output. This is especially the case for web applications if the expected result is a web page with a lot of HTML.Doctest and Documentation generators
Both the [http://epydoc.sourceforge.net/epytextintro.html EpyText] format of
Epydoc , and the [http://docutils.sourceforge.net/rst.html reStructuredText] format of [http://docutils.sourceforge.net/index.html Docutils] , support the markup of doctest sections within docstrings.References
* cite newsgroup
author = Tim Peters
date = 1999-03-06
title = docstring-driven testing
id = 000001be679b$0b263e00$a99e2299@tim
url = http://groups.google.com/group/comp.lang.python/msg/1c57cfb7b3772763
* cite web
title = Development Tools – doctest
work = Python Library Reference
url = http://python.org/doc/current/lib/module-doctest.html
date = 2006-09-19
* [http://blog.ianbicking.org/minimock.html minimock] - Minimalist mock object implementation for doctest by Ian Bicking.
* [http://github.com/tablatom/rubydoctest/wikis Doctest for Ruby and Rails] .
* [http://svn.colorstudy.com/doctestjs/trunk/docs/index.html Doctest/JS] an implementation for Javascript.
* [http://www.cis.upenn.edu/~edloper/projects/doctestmode/ doctest-mode] - Emacs mode for editing doctests.
Wikimedia Foundation. 2010.