Such a working environment for the testing code is called a
:dfn:`test fixture`. A new TestCase instance is created as a unique
test fixture used to execute each individual test method. Thus
-:meth:`~TestCase.setUp`, :meth:`~TestCase.tearDown`, and :meth:`~TestCase.__init__`
+:meth:`~TestCase.setUp`, :meth:`~TestCase.tearDown`, and :meth:`!TestCase.__init__`
will be called once per test.
It is recommended that you use TestCase implementations to group tests together
subclasses will make future test refactorings infinitely easier.
In some cases, the existing tests may have been written using the :mod:`doctest`
-module. If so, :mod:`doctest` provides a :class:`DocTestSuite` class that can
+module. If so, :mod:`doctest` provides a :class:`~doctest.DocTestSuite` class that can
automatically build :class:`unittest.TestSuite` instances from the existing
:mod:`doctest`\ -based tests.
additional keyword argument *msg*.
The context manager will store the caught exception object in its
- :attr:`exception` attribute. This can be useful if the intention
+ :attr:`!exception` attribute. This can be useful if the intention
is to perform additional checks on the exception raised::
with self.assertRaises(SomeException) as cm:
Added the ability to use :meth:`assertRaises` as a context manager.
.. versionchanged:: 3.2
- Added the :attr:`exception` attribute.
+ Added the :attr:`!exception` attribute.
.. versionchanged:: 3.3
Added the *msg* keyword argument when used as a context manager.
additional keyword argument *msg*.
The context manager will store the caught warning object in its
- :attr:`warning` attribute, and the source line which triggered the
- warnings in the :attr:`filename` and :attr:`lineno` attributes.
+ :attr:`!warning` attribute, and the source line which triggered the
+ warnings in the :attr:`!filename` and :attr:`!lineno` attributes.
This can be useful if the intention is to perform additional checks
on the warning caught::
that lists the differences between the sets. This method is used by
default when comparing sets or frozensets with :meth:`assertEqual`.
- Fails if either of *first* or *second* does not have a :meth:`set.difference`
+ Fails if either of *first* or *second* does not have a :meth:`~frozenset.difference`
method.
.. versionadded:: 3.1
.. method:: asyncSetUp()
:async:
- Method called to prepare the test fixture. This is called after :meth:`setUp`.
+ Method called to prepare the test fixture. This is called after :meth:`TestCase.setUp`.
This is called immediately before calling the test method; other than
:exc:`AssertionError` or :exc:`SkipTest`, any exception raised by this method
will be considered an error rather than a test failure. The default implementation
:async:
Method called immediately after the test method has been called and the
- result recorded. This is called before :meth:`tearDown`. This is called even if
+ result recorded. This is called before :meth:`~TestCase.tearDown`. This is called even if
the test method raised an exception, so the implementation in subclasses may need
to be particularly careful about checking internal state. Any exception, other than
:exc:`AssertionError` or :exc:`SkipTest`, raised by this method will be
Sets up a new event loop to run the test, collecting the result into
the :class:`TestResult` object passed as *result*. If *result* is
omitted or ``None``, a temporary result object is created (by calling
- the :meth:`defaultTestResult` method) and used. The result object is
+ the :meth:`~TestCase.defaultTestResult` method) and used. The result object is
returned to :meth:`run`'s caller. At the end of the test all the tasks
in the event loop are cancelled.
returned by repeated iterations before :meth:`TestSuite.run` must be the
same for each call iteration. After :meth:`TestSuite.run`, callers should
not rely on the tests returned by this method unless the caller uses a
- subclass that overrides :meth:`TestSuite._removeTestAtIndex` to preserve
+ subclass that overrides :meth:`!TestSuite._removeTestAtIndex` to preserve
test references.
.. versionchanged:: 3.2
.. versionchanged:: 3.4
In earlier versions the :class:`TestSuite` held references to each
:class:`TestCase` after :meth:`TestSuite.run`. Subclasses can restore
- that behavior by overriding :meth:`TestSuite._removeTestAtIndex`.
+ that behavior by overriding :meth:`!TestSuite._removeTestAtIndex`.
In the typical usage of a :class:`TestSuite` object, the :meth:`run` method
- is invoked by a :class:`TestRunner` rather than by the end-user test harness.
+ is invoked by a :class:`!TestRunner` rather than by the end-user test harness.
Loading and running tests
.. method:: loadTestsFromTestCase(testCaseClass)
Return a suite of all test cases contained in the :class:`TestCase`\ -derived
- :class:`testCaseClass`.
+ :class:`!testCaseClass`.
A test case instance is created for each method named by
:meth:`getTestCaseNames`. By default these are the method names
beginning with ``test``. If :meth:`getTestCaseNames` returns no
- methods, but the :meth:`runTest` method is implemented, a single test
+ methods, but the :meth:`!runTest` method is implemented, a single test
case is created for that method instead.
case class will be picked up as "a test method within a test case class",
rather than "a callable object".
- For example, if you have a module :mod:`SampleTests` containing a
- :class:`TestCase`\ -derived class :class:`SampleTestCase` with three test
- methods (:meth:`test_one`, :meth:`test_two`, and :meth:`test_three`), the
+ For example, if you have a module :mod:`!SampleTests` containing a
+ :class:`TestCase`\ -derived class :class:`!SampleTestCase` with three test
+ methods (:meth:`!test_one`, :meth:`!test_two`, and :meth:`!test_three`), the
specifier ``'SampleTests.SampleTestCase'`` would cause this method to
return a suite which will run all three test methods. Using the specifier
``'SampleTests.SampleTestCase.test_two'`` would cause it to return a test
- suite which will run only the :meth:`test_two` test method. The specifier
+ suite which will run only the :meth:`!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.
Testing frameworks built on top of :mod:`unittest` may want access to the
:class:`TestResult` object generated by running a set of tests for reporting
purposes; a :class:`TestResult` instance is returned by the
- :meth:`TestRunner.run` method for this purpose.
+ :meth:`!TestRunner.run` method for this purpose.
:class:`TestResult` instances have the following attributes that will be of
interest when inspecting the results of running a set of tests:
This method can be called to signal that the set of tests being run should
be aborted by setting the :attr:`shouldStop` attribute to ``True``.
- :class:`TestRunner` objects should respect this flag and return without
+ :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`
+ keyboard. Interactive tools which provide :class:`!TestRunner`
implementations can use this in a similar manner.
The following methods of the :class:`TestResult` class are used to maintain
-------------------------
Class and module level fixtures are implemented in :class:`TestSuite`. When
-the test suite encounters a test from a new class then :meth:`tearDownClass`
-from the previous class (if there is one) is called, followed by
-:meth:`setUpClass` from the new class.
+the test suite encounters a test from a new class then
+:meth:`~TestCase.tearDownClass` from the previous class (if there is one)
+is called, followed by :meth:`~TestCase.setUpClass` from the new class.
Similarly if a test is from a different module from the previous test then
``tearDownModule`` from the previous module is run, followed by
projects / thirdparty / Python / cpython.git / commitdiff
