@@ -65,7 +65,7 @@ \section{\module{doctest} ---
6565 raise ValueError("n must be >= 0")
6666 if math.floor(n) != n:
6767 raise ValueError("n must be exact integer")
68- if n+1 == n: # e.g., 1e300
68+ if n+1 == n: # catch a value like 1e300
6969 raise OverflowError("n too large")
7070 result = 1
7171 factor = 2
@@ -243,13 +243,75 @@ \subsection{What About Exceptions?}
243243
244244\subsection {Advanced Usage }
245245
246- \function {testmod()} actually creates a local instance of class
247- \class {Tester}, runs appropriate methods of that class, and merges
248- the results into global \class {Tester} instance \code {master}.
249-
250- You can create your own instances of \class {Tester}, and so build your
251- own policies, or even run methods of \code {master} directly. See
252- \code {Tester.__doc__} for details.
246+ Several module level functions are available for controlling how doctests
247+ are run.
248+
249+ \begin {funcdesc }{debug}{module, name}
250+ Debug a single docstring containing doctests.
251+
252+ Provide the \var {module} (or dotted name of the module) containing the
253+ docstring to be debugged and the \var {name} (within the module) of the
254+ object with the docstring to be debugged.
255+
256+ The doctest examples are extracted (see function \function {testsource()}),
257+ and written to a temporary file. The Python debugger, \refmodule {pdb},
258+ is then invoked on that file.
259+ \versionadded {2.3}
260+ \end {funcdesc }
261+
262+ \begin {funcdesc }{testmod}{}
263+ This function provides the most basic interface to the doctests.
264+ It creates a local instance of class \class {Tester}, runs appropriate
265+ methods of that class, and merges the results into the global \class {Tester}
266+ instance, \code {master}.
267+
268+ To get finer control than \function {testmod()} offers, create an instance
269+ of \class {Tester} with custom policies and run the methods of \code {master}
270+ directly. See \code {Tester.__doc__} for details.
271+ \end {funcdesc }
272+
273+ \begin {funcdesc }{testsource}{module, name}
274+ Extract the doctest examples from a docstring.
275+
276+ Provide the \var {module} (or dotted name of the module) containing the
277+ tests to be extracted and the \var {name} (within the module) of the object
278+ with the docstring containing the tests to be extracted.
279+
280+ The doctest examples are returned as a string containing Python
281+ code. The expected output blocks in the examples are converted
282+ to Python comments.
283+ \versionadded {2.3}
284+ \end {funcdesc }
285+
286+ \begin {funcdesc }{DocTestSuite}{\optional {module}}
287+ Convert doctest tests for a module to a \refmodule {unittest}
288+ \class {TestSuite}.
289+
290+ The returned \class {TestSuite} is to be run by the unittest framework
291+ and runs each doctest in the module. If any of the doctests fail,
292+ then the synthesized unit test fails, and a \exception {DocTestTestFailure}
293+ exception is raised showing the name of the file containing the test and a
294+ (sometimes approximate) line number.
295+
296+ The optional \var {module} argument provides the module to be tested. It
297+ can be a module object or a (possibly dotted) module name. If not
298+ specified, the module calling \function {DocTestSuite()} is used.
299+
300+ Example using one of the many ways that the \refmodule {unittest} module
301+ can use a \class {TestSuite}:
302+
303+ \begin {verbatim }
304+ import unittest
305+ import doctest
306+ import my_module_with_doctests
307+
308+ suite = doctest.DocTestSuite(my_module_with_doctests)
309+ runner = unittest.TextTestRunner()
310+ runner.run(suite)
311+ \end {verbatim }
312+
313+ \versionadded {2.3}
314+ \end {funcdesc }
253315
254316
255317\subsection {How are Docstring Examples Recognized? }
0 commit comments