traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Patch #1534922: correct and enhance unittest docs.

This commit is contained in:
Georg Brandl 2006-08-05 06:10:54 +00:00
parent e6c9f982a0
commit 212b587a52
2 changed files with 181 additions and 142 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

316
Doc/lib/libunittest.tex
View File

@ -10,19 +10,19 @@
\versionadded{2.1}
The Python unit testing framework, often referred to as ``PyUnit,'' is
The Python unit testing framework, sometimes referred to as ``PyUnit,'' is
a Python language version of JUnit, by Kent Beck and Erich Gamma.
JUnit is, in turn, a Java version of Kent's Smalltalk testing
framework. Each is the de facto standard unit testing framework for
its respective language.
PyUnit supports test automation, sharing of setup and shutdown code
for tests, aggregation of tests into collections, and independence of
\module{unittest} supports test automation, sharing of setup and shutdown
code for tests, aggregation of tests into collections, and independence of
the tests from the reporting framework. The \module{unittest} module
provides classes that make it easy to support these qualities for a
set of tests.
To achieve this, PyUnit supports some important concepts:
To achieve this, \module{unittest} supports some important concepts:
\begin{definitions}
\term{test fixture}
@ -33,10 +33,9 @@ starting a server process.
\term{test case}
A \dfn{test case} is the smallest unit of testing. It checks for a
specific response to a particular set of inputs. PyUnit provides a
base class, \class{TestCase}, which may be used to create new test
cases. You may provide your own implementation that does not subclass
from \class{TestCase}, of course.
specific response to a particular set of inputs. \module{unittest}
provides a base class, \class{TestCase}, which may be used to create
new test cases.
\term{test suite}
A \dfn{test suite} is a collection of test cases, test suites, or
@ -54,8 +53,8 @@ indicate the results of executing the tests.
The test case and test fixture concepts are supported through the
\class{TestCase} and \class{FunctionTestCase} classes; the former
should be used when creating new tests, and the latter can be used when
integrating existing test code with a PyUnit-driven framework. When
building test fixtures using \class{TestCase}, the \method{setUp()}
integrating existing test code with a \module{unittest}-driven framework.
When building test fixtures using \class{TestCase}, the \method{setUp()}
and \method{tearDown()} methods can be overridden to provide
initialization and cleanup for the fixture. With
\class{FunctionTestCase}, existing functions can be passed to the
@ -74,19 +73,17 @@ the suite is executed, all tests added directly to the suite and in
A test runner is an object that provides a single method,
\method{run()}, which accepts a \class{TestCase} or \class{TestSuite}
object as a parameter, and returns a result object. The class
\class{TestResult} is provided for use as the result object. PyUnit
provide the \class{TextTestRunner} as an example test runner which
reports test results on the standard error stream by default.
Alternate runners can be implemented for other environments (such as
graphical environments) without any need to derive from a specific
class.
\class{TestResult} is provided for use as the result object.
\module{unittest} provides the \class{TextTestRunner} as an example
test runner which reports test results on the standard error stream by
default. Alternate runners can be implemented for other environments
(such as graphical environments) without any need to derive from a
specific class.
\begin{seealso}
\seemodule{doctest}{Another test-support module with a very
different flavor.}
\seetitle[http://pyunit.sourceforge.net/]{PyUnit Web Site}{The
source for further information on PyUnit.}
\seetitle[http://www.XProgramming.com/testfram.htm]{Simple Smalltalk
Testing: With Patterns}{Kent Beck's original paper on
testing frameworks using the pattern shared by
@ -166,7 +163,7 @@ run from the command line. For example, the last two lines may be replaced
with:
\begin{verbatim}
suite = unittest.makeSuite(TestSequenceFunctions)
suite = unittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions)
unittest.TextTestRunner(verbosity=2).run(suite)
\end{verbatim}
@ -194,8 +191,8 @@ of the documentation explores the full feature set from first principles.
The basic building blocks of unit testing are \dfn{test cases} ---
single scenarios that must be set up and checked for correctness. In
PyUnit, test cases are represented by instances of the
\class{TestCase} class in the \refmodule{unittest} module. To make
\module{unittest}, test cases are represented by instances of
\module{unittest}'s \class{TestCase} class. To make
your own test cases you must write subclasses of \class{TestCase}, or
use \class{FunctionTestCase}.
@ -207,7 +204,7 @@ The testing code of a \class{TestCase} instance should be entirely
self contained, such that it can be run either in isolation or in
arbitrary combination with any number of other test cases.
The simplest test case subclass will simply override the
The simplest \class{TestCase} subclass will simply override the
\method{runTest()} method in order to perform specific testing code:
\begin{verbatim}
@ -221,12 +218,13 @@ class DefaultWidgetSizeTestCase(unittest.TestCase):
Note that in order to test something, we use the one of the
\method{assert*()} or \method{fail*()} methods provided by the
\class{TestCase} base class. If the test fails when the test case
runs, an exception will be raised, and the testing framework will
identify the test case as a \dfn{failure}. Other exceptions that do
not arise from checks made through the \method{assert*()} and
\method{fail*()} methods are identified by the testing framework as
\dfn{errors}.
\class{TestCase} base class. If the test fails, an exception will be
raised, and \module{unittest} will identify the test case as a
\dfn{failure}. Any other exceptions will be treated as \dfn{errors}.
This helps you identify where the problem is: \dfn{failures} are caused by
incorrect results - a 5 where you expected a 6. \dfn{Errors} are caused by
incorrect code - e.g., a \exception{TypeError} caused by an incorrect
function call.
The way to run a test case will be described later. For now, note
that to construct an instance of such a test case, we call its
@ -237,7 +235,7 @@ testCase = DefaultWidgetSizeTestCase()
\end{verbatim}
Now, such test cases can be numerous, and their set-up can be
repetitive. In the above case, constructing a ``Widget'' in each of
repetitive. In the above case, constructing a \class{Widget} in each of
100 Widget test case subclasses would mean unsightly duplication.
Luckily, we can factor out such set-up code by implementing a method
@ -283,7 +281,7 @@ class SimpleWidgetTestCase(unittest.TestCase):
\end{verbatim}
If \method{setUp()} succeeded, the \method{tearDown()} method will be
run regardless of whether or not \method{runTest()} succeeded.
run whether \method{runTest()} succeeded or not.
Such a working environment for the testing code is called a
\dfn{fixture}.
@ -292,8 +290,8 @@ Often, many small test cases will use the same fixture. In this case,
we would end up subclassing \class{SimpleWidgetTestCase} into many
small one-method classes such as
\class{DefaultWidgetSizeTestCase}. This is time-consuming and
discouraging, so in the same vein as JUnit, PyUnit provides a simpler
mechanism:
discouraging, so in the same vein as JUnit, \module{unittest} provides
a simpler mechanism:
\begin{verbatim}
import unittest
@ -329,9 +327,9 @@ resizeTestCase = WidgetTestCase("testResize")
\end{verbatim}
Test case instances are grouped together according to the features
they test. PyUnit provides a mechanism for this: the \class{test
suite}, represented by the class \class{TestSuite} in the
\refmodule{unittest} module:
they test. \module{unittest} provides a mechanism for this: the
\dfn{test suite}, represented by \module{unittest}'s \class{TestSuite}
class:
\begin{verbatim}
widgetTestSuite = unittest.TestSuite()
@ -354,28 +352,30 @@ def suite():
or even:
\begin{verbatim}
class WidgetTestSuite(unittest.TestSuite):
def __init__(self):
unittest.TestSuite.__init__(self,map(WidgetTestCase,
("testDefaultSize",
"testResize")))
\end{verbatim}
def suite():
tests = ["testDefaultSize", "testResize"]
(The latter is admittedly not for the faint-hearted!)
return unittest.TestSuite(map(WidgetTestCase, tests))
\end{verbatim}
Since it is a common pattern to create a \class{TestCase} subclass
with many similarly named test functions, there is a convenience
function called \function{makeSuite()} that constructs a test suite
that comprises all of the test cases in a test case class:
with many similarly named test functions, \module{unittest} provides a
\class{TestLoader} class that can be used to automate the process of
creating a test suite and populating it with individual tests.
For example,
\begin{verbatim}
suite = unittest.makeSuite(WidgetTestCase)
suite = unittest.TestLoader().loadTestsFromTestCase(WidgetTestCase)
\end{verbatim}
Note that when using the \function{makeSuite()} function, the order in
which the various test cases will be run by the test suite is the
order determined by sorting the test function names using the
\function{cmp()} built-in function.
will create a test suite that will run
\code{WidgetTestCase.testDefaultSize()} and \code{WidgetTestCase.testResize}.
\class{TestLoader} uses the \code{'test'} method name prefix to identify
test methods automatically.
Note that the order in which the various test cases will be run is
determined by sorting the test function names with the built-in
\function{cmp()} function.
Often it is desirable to group suites of test cases together, so as to
run tests for the whole system at once. This is easy, since
@ -385,13 +385,13 @@ as \class{TestCase} instances can be added to a \class{TestSuite}:
\begin{verbatim}
suite1 = module1.TheTestSuite()
suite2 = module2.TheTestSuite()
alltests = unittest.TestSuite((suite1, suite2))
alltests = unittest.TestSuite([suite1, suite2])
\end{verbatim}
You can place the definitions of test cases and test suites in the
same modules as the code they are to test (such as \file{widget.py}),
but there are several advantages to placing the test code in a
separate module, such as \file{widgettests.py}:
separate module, such as \file{test_widget.py}:
\begin{itemize}
\item The test module can be run standalone from the command line.
@ -412,13 +412,12 @@ separate module, such as \file{widgettests.py}:
\label{legacy-unit-tests}}
Some users will find that they have existing test code that they would
like to run from PyUnit, without converting every old test function to
a \class{TestCase} subclass.
like to run from \module{unittest}, without converting every old test
function to a \class{TestCase} subclass.
For this reason, PyUnit provides a \class{FunctionTestCase} class.
This subclass of \class{TestCase} can be used to wrap an existing test
function. Set-up and tear-down functions can also optionally be
wrapped.
For this reason, \module{unittest} provides a \class{FunctionTestCase}
class. This subclass of \class{TestCase} can be used to wrap an existing
test function. Set-up and tear-down functions can also be provided.
Given the following test function:
@ -436,7 +435,8 @@ testcase = unittest.FunctionTestCase(testSomething)
\end{verbatim}
If there are additional set-up and tear-down methods that should be
called as part of the test case's operation, they can also be provided:
called as part of the test case's operation, they can also be provided
like so:
\begin{verbatim}
testcase = unittest.FunctionTestCase(testSomething,
@ -444,9 +444,19 @@ testcase = unittest.FunctionTestCase(testSomething,
tearDown=deleteSomethingDB)
\end{verbatim}
\note{PyUnit supports the use of \exception{AssertionError}
as an indicator of test failure, but does not recommend it. Future
versions may treat \exception{AssertionError} differently.}
To make migrating existing test suites easier, \module{unittest}
supports tests raising \exception{AssertionError} to indicate test failure.
However, it is recommended that you use the explicit
\method{TestCase.fail*()} and \method{TestCase.assert*()} methods instead,
as future versions of \module{unittest} may treat \exception{AssertionError}
differently.
\note{Even though \class{FunctionTestCase} can be used to quickly convert
an existing test base over to a \module{unittest}-based system, this
approach is not recommended. Taking the time to set up proper
\class{TestCase} subclasses will make future test refactorings infinitely
easier.}
\subsection{Classes and functions
@ -454,11 +464,12 @@ versions may treat \exception{AssertionError} differently.}
\begin{classdesc}{TestCase}{}
Instances of the \class{TestCase} class represent the smallest
testable units in a set of tests. This class is intended to be used
as a base class, with specific tests being implemented by concrete
subclasses. This class implements the interface needed by the test
runner to allow it to drive the test, and methods that the test code
can use to check for and report various kinds of failures.
testable units in the \module{unittest} universe. This class is
intended to be used as a base class, with specific tests being
implemented by concrete subclasses. This class implements the
interface needed by the test runner to allow it to drive the
test, and methods that the test code can use to check for and
report various kinds of failure.
\end{classdesc}
\begin{classdesc}{FunctionTestCase}{testFunc\optional{,
@ -474,33 +485,33 @@ versions may treat \exception{AssertionError} differently.}
\begin{classdesc}{TestSuite}{\optional{tests}}
This class represents an aggregation of individual tests cases and
test suites. The class presents the interface needed by the test
runner to allow it to be run as any other test case, but all the
contained tests and test suites are executed. Additional methods
are provided to add test cases and suites to the aggregation. If
\var{tests} is given, it must be a sequence of individual tests that
will be added to the suite.
runner to allow it to be run as any other test case. Running a
\class{TestSuite} instance is the same as iterating over the suite,
running each test individually.
If \var{tests} is given, it must be an iterable of individual test cases or
other test suites that will be used to build the suite initially.
Additional methods are provided to add test cases and suites to the
collection later on.
\end{classdesc}
\begin{classdesc}{TestLoader}{}
This class is responsible for loading tests according to various
criteria and returning them wrapped in a \class{TestSuite}.
It can load all tests within a given module or \class{TestCase}
class. When loading from a module, it considers all
\class{TestCase}-derived classes. For each such class, it creates
an instance for each method with a name beginning with the string
\samp{test}.
subclass.
\end{classdesc}
\begin{datadesc}{defaultTestLoader}
Instance of the \class{TestLoader} class which can be shared. If no
Instance of the \class{TestLoader} class intended to be shared. If no
customization of the \class{TestLoader} is needed, this instance can
always be used instead of creating new instances.
be used instead of repeatedly creating new instances.
\end{datadesc}
\begin{classdesc}{TextTestRunner}{\optional{stream\optional{,
descriptions\optional{, verbosity}}}}
A basic test runner implementation which prints results on standard
output. It has a few configurable parameters, but is essentially
error. It has a few configurable parameters, but is essentially
very simple. Graphical applications which run test suites should
provide alternate implementations.
\end{classdesc}
@ -510,7 +521,8 @@ versions may treat \exception{AssertionError} differently.}
testRunner\optional{, testRunner}}}}}}
A command-line program that runs a set of tests; this is primarily
for making test modules conveniently executable. The simplest use
for this function is:
for this function is to include the following line at the end of a
test script:
\begin{verbatim}
if __name__ == '__main__':
@ -518,10 +530,11 @@ if __name__ == '__main__':
\end{verbatim}
\end{funcdesc}
In some cases, the existing tests may have be written using the
In some cases, the existing tests may have been written using the
\refmodule{doctest} module. If so, that module provides a
\class{DocTestSuite} class that can automatically build
\class{unittest.TestSuite} instances from the existing test code.
\class{unittest.TestSuite} instances from the existing
\module{doctest}-based tests.
\versionadded{2.3}
@ -538,7 +551,7 @@ used to run the test, another used by the test implementation to
check conditions and report failures, and some inquiry methods
allowing information about the test itself to be gathered.
Methods in the first group are:
Methods in the first group (running the test) are:
\begin{methoddesc}[TestCase]{setUp}{}
Method called to prepare the test fixture. This is called
@ -562,8 +575,10 @@ Methods in the first group are:
Run the test, collecting the result into the test result object
passed as \var{result}. If \var{result} is omitted or \constant{None},
a temporary result object is created and used, but is not made
available to the caller. This is equivalent to simply calling the
\class{TestCase} instance.
available to the caller.
The same effect may be had by simply calling the \class{TestCase}
instance.
\end{methoddesc}
\begin{methoddesc}[TestCase]{debug}{}
@ -664,10 +679,8 @@ Testing frameworks can use the following methods to collect
information on the test:
\begin{methoddesc}[TestCase]{countTestCases}{}
Return the number of tests represented by the this test object. For
\class{TestCase} instances, this will always be \code{1}, but this
method is also implemented by the \class{TestSuite} class, which can
return larger values.
Return the number of tests represented by this test object. For
\class{TestCase} instances, this will always be \code{1}.
\end{methoddesc}
\begin{methoddesc}[TestCase]{defaultTestResult}{}
@ -678,7 +691,7 @@ information on the test:
\begin{methoddesc}[TestCase]{id}{}
Return a string identifying the specific test case. This is usually
the full name of the test method, including the module and class
names.
name.
\end{methoddesc}
\begin{methoddesc}[TestCase]{shortDescription}{}
@ -694,21 +707,23 @@ information on the test:
\class{TestSuite} objects behave much like \class{TestCase} objects,
except they do not actually implement a test. Instead, they are used
to aggregate tests into groups that should be run together. Some
additional methods are available to add tests to \class{TestSuite}
to aggregate tests into groups of tests that should be run together.
Some additional methods are available to add tests to \class{TestSuite}
instances:
\begin{methoddesc}[TestSuite]{addTest}{test}
Add a \class{TestCase} or \class{TestSuite} to the set of tests that
make up the suite.
Add a \class{TestCase} or \class{TestSuite} to the suite.
\end{methoddesc}
\begin{methoddesc}[TestSuite]{addTests}{tests}
Add all the tests from a sequence of \class{TestCase} and
Add all the tests from an iterable of \class{TestCase} and
\class{TestSuite} instances to this test suite.
This is equivalent to iterating over \var{tests}, calling
\method{addTest()} for each element.
\end{methoddesc}
The \method{run()} method is also slightly different:
\class{TestSuite} shares the following methods with \class{TestCase}:
\begin{methoddesc}[TestSuite]{run}{result}
Run the tests associated with this suite, collecting the result into
@ -717,6 +732,17 @@ The \method{run()} method is also slightly different:
result object to be passed in.
\end{methoddesc}
\begin{methoddesc}[TestSuite]{debug}{}
Run the tests associated with this suite without collecting the result.
This allows exceptions raised by the test to be propagated to the caller
and can be used to support running tests under a debugger.
\end{methoddesc}
\begin{methoddesc}[TestSuite]{countTestCases}{}
Return the number of tests represented by this test object, including
all individual tests and sub-suites.
\end{methoddesc}
In the typical usage of a \class{TestSuite} object, the \method{run()}
method is invoked by a \class{TestRunner} rather than by the end-user
test harness.
@ -727,7 +753,7 @@ test harness.
A \class{TestResult} object stores the results of a set of tests. The
\class{TestCase} and \class{TestSuite} classes ensure that results are
properly stored; test authors do not need to worry about recording the
properly recorded; test authors do not need to worry about recording the
outcome of tests.
Testing frameworks built on top of \refmodule{unittest} may want
@ -745,28 +771,41 @@ formatted version of the traceback for the exception.
be of interest when inspecting the results of running a set of tests:
\begin{memberdesc}[TestResult]{errors}
A list containing pairs of \class{TestCase} instances and the
formatted tracebacks for tests which raised an exception but did not
signal a test failure.
A list containing 2-tuples of \class{TestCase} instances and
formatted tracebacks. Each tuple represents a test which raised an
unexpected exception.
\versionchanged[Contains formatted tracebacks instead of
\function{sys.exc_info()} results]{2.2}
\end{memberdesc}
\begin{memberdesc}[TestResult]{failures}
A list containing pairs of \class{TestCase} instances and the
formatted tracebacks for tests which signalled a failure in the code
under test.
A list containing 2-tuples of \class{TestCase} instances and
formatted tracebacks. Each tuple represents a test where a failure
was explicitly signalled using the \method{TestCase.fail*()} or
\method{TestCase.assert*()} methods.
\versionchanged[Contains formatted tracebacks instead of
\function{sys.exc_info()} results]{2.2}
\end{memberdesc}
\begin{memberdesc}[TestResult]{testsRun}
The number of tests which have been started.
The total number of tests run so far.
\end{memberdesc}
\begin{methoddesc}[TestResult]{wasSuccessful}{}
Returns true if all tests run so far have passed, otherwise returns
false.
Returns \constant{True} if all tests run so far have passed,
otherwise returns \constant{False}.
\end{methoddesc}
\begin{methoddesc}[TestResult]{stop}{}
This method can be called to signal that the set of tests being run
should be aborted by setting the \class{TestResult}'s \code{shouldStop}
attribute to \constant{True}. \class{TestRunner} objects should respect
this flag and return without running any additional tests.
For example, this feature is used by the \class{TextTestRunner} class
to stop the test framework when the user signals an interrupt from
the keyboard. Interactive tools which provide \class{TestRunner}
implementations can use this in a similar manner.
\end{methoddesc}
@ -786,10 +825,9 @@ reporting while tests are being run.
\end{methoddesc}
\begin{methoddesc}[TestResult]{addError}{test, err}
Called when the test case \var{test} raises an exception without
signalling a test failure. \var{err} is a tuple of the form
returned by \function{sys.exc_info()}: \code{(\var{type},
\var{value}, \var{traceback})}.
Called when the test case \var{test} raises an unexpected exception
\var{err} is a tuple of the form returned by \function{sys.exc_info()}:
\code{(\var{type}, \var{value}, \var{traceback})}.
\end{methoddesc}
\begin{methoddesc}[TestResult]{addFailure}{test, err}
@ -800,23 +838,10 @@ reporting while tests are being run.
\end{methoddesc}
\begin{methoddesc}[TestResult]{addSuccess}{test}
This method is called for a test that does not fail; \var{test} is
the test case object.
Called when the test case \var{test} succeeds.
\end{methoddesc}
One additional method is available for \class{TestResult} objects:
\begin{methoddesc}[TestResult]{stop}{}
This method can be called to signal that the set of tests being run
should be aborted. Once this has been called, the
\class{TestRunner} object return to its caller without running any
additional tests. This is used by the \class{TextTestRunner} class
to stop the test framework when the user signals an interrupt from
the keyboard. Interactive tools which provide runners can use this
in a similar manner.
\end{methoddesc}
\subsection{TestLoader Objects
\label{testloader-objects}}
@ -824,15 +849,15 @@ One additional method is available for \class{TestResult} objects:
The \class{TestLoader} class is used to create test suites from
classes and modules. Normally, there is no need to create an instance
of this class; the \refmodule{unittest} module provides an instance
that can be shared as the \code{defaultTestLoader} module attribute.
Using a subclass or instance would allow customization of some
that can be shared as \code{unittest.defaultTestLoader}.
Using a subclass or instance, however, allows customization of some
configurable properties.
\class{TestLoader} objects have the following methods:
\begin{methoddesc}[TestLoader]{loadTestsFromTestCase}{testCaseClass}
Return a suite of all tests cases contained in the
\class{TestCase}-derived class \class{testCaseClass}.
\class{TestCase}-derived \class{testCaseClass}.
\end{methoddesc}
\begin{methoddesc}[TestLoader]{loadTestsFromModule}{module}
@ -842,7 +867,7 @@ configurable properties.
method defined for the class.
\warning{While using a hierarchy of
\class{Testcase}-derived classes can be convenient in sharing
\class{TestCase}-derived classes can be convenient in sharing
fixtures and helper functions, defining test methods on base classes
that are not intended to be instantiated directly does not play well
with this method. Doing so, however, can be useful when the
@ -853,21 +878,23 @@ configurable properties.
Return a suite of all tests cases given a string specifier.
The specifier \var{name} is a ``dotted name'' that may resolve
either to a module, a test case class, a test method within a test
case class, or a callable object which returns a \class{TestCase} or
\class{TestSuite} instance. For example, if you have a module
\module{SampleTests} containing a \class{TestCase}-derived class
\class{SampleTestCase} with three test methods (\method{test_one()},
\method{test_two()}, and \method{test_three()}), the specifier
\code{'SampleTests.SampleTestCase'} would cause this method to
return a suite which will run all three test methods. Using the
specifier \code{'SampleTests.SampleTestCase.test_two'} would cause
it to return a test suite which will run only the
either to a module, a test case class, a \class{TestSuite} instance,
a test method within a test case class, or a callable object which
returns a \class{TestCase} or \class{TestSuite} instance.
For example, if you have a module \module{SampleTests} containing a
\class{TestCase}-derived class \class{SampleTestCase} with three test
methods (\method{test_one()}, \method{test_two()}, and
\method{test_three()}), the specifier \code{'SampleTests.SampleTestCase'}
would cause this method to return a suite which will run all three test
methods. Using the specifier \code{'SampleTests.SampleTestCase.test_two'}
would cause it to return a test suite which will run only the
\method{test_two()} test method. The specifier can refer to modules
and packages which have not been imported; they will be imported as
a side-effect.
The method optionally resolves \var{name} relative to a given module.
The method optionally resolves \var{name} relative to the given
\var{module}.
\end{methoddesc}
\begin{methoddesc}[TestLoader]{loadTestsFromNames}{names\optional{, module}}
@ -888,17 +915,22 @@ either by subclassing or assignment on an instance:
\begin{memberdesc}[TestLoader]{testMethodPrefix}
String giving the prefix of method names which will be interpreted
as test methods. The default value is \code{'test'}.
This affects \method{getTestCaseNames()} and all the
\method{loadTestsFrom*()} methods.
\end{memberdesc}
\begin{memberdesc}[TestLoader]{sortTestMethodsUsing}
Function to be used to compare method names when sorting them in
\method{getTestCaseNames()}. The default value is the built-in
\function{cmp()} function; it can be set to \constant{None} to disable
the sort.
\method{getTestCaseNames()} and all the \method{loadTestsFrom*()} methods.
The default value is the built-in \function{cmp()} function; the attribute
can also be set to \constant{None} to disable the sort.
\end{memberdesc}
\begin{memberdesc}[TestLoader]{suiteClass}
Callable object that constructs a test suite from a list of tests.
No methods on the resulting object are needed. The default value is
the \class{TestSuite} class.
This affects all the \method{loadTestsFrom*()} methods.
\end{memberdesc}

7
Misc/NEWS
View File

@ -49,6 +49,12 @@ Tests
-----
Documentation
-------------
- Patch #1534922: unittest docs were corrected and enhanced.
Build
-----
@ -433,6 +439,7 @@ Documentation
- Patch #1504046: Add documentation for xml.etree.
What's New in Python 2.5 beta 1?
================================