@@ -65,7 +65,7 @@ \section{\module{doctest} ---
65
65
raise ValueError("n must be >= 0")
66
66
if math.floor(n) != n:
67
67
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
69
69
raise OverflowError("n too large")
70
70
result = 1
71
71
factor = 2
@@ -243,13 +243,75 @@ \subsection{What About Exceptions?}
243
243
244
244
\subsection {Advanced Usage }
245
245
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 }
253
315
254
316
255
317
\subsection {How are Docstring Examples Recognized? }
0 commit comments