Mirror
/
cpython
mirror of https://github.com/python/cpython
4
1
Fork 0
Code Issues Releases Wiki Activity

unittest documentation formatting changes

This commit is contained in:
Michael Foord 2010-04-04 22:41:54 +00:00
parent 06bc0b6d2e
commit 09e2980c15
1 changed files with 37 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
Doc/library/unittest.rst
View File

@ -617,8 +617,8 @@ The following decorators implement test skipping and expected failures:
Mark the test as an expected failure. If the test fails when run, the test
is not counted as a failure.
Skipped tests will not have :meth:`setUp` or :meth:`tearDown` run around them. Skipped classes
will not have :meth:`setUpClass` or :meth:`tearDownClass` run.
Skipped tests will not have :meth:`setUp` or :meth:`tearDown` run around them.
Skipped classes will not have :meth:`setUpClass` or :meth:`tearDownClass` run.
.. _unittest-contents:
@ -689,7 +689,7 @@ Test cases
A class method called before tests in an individual class run.
``setUpClass`` is called with the class as the only argument
and must be decorated as a :meth:`classmethod`::
and must be decorated as a :func:`classmethod`::
@classmethod
def setUpClass(cls):
@ -1770,19 +1770,38 @@ continue (and potentially modify) test discovery. A 'do nothing'
Class and Module Fixtures
-------------------------
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.
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.
Similarly if a test is from a different module from the previous test then ``tearDownModule`` from the previous module is run, followed by ``setUpModule`` from the new module.
Similarly if a test is from a different module from the previous test then
``tearDownModule`` from the previous module is run, followed by
``setUpModule`` from the new module.
After all the tests have run the final ``tearDownClass`` and ``tearDownModule`` are run.
After all the tests have run the final ``tearDownClass`` and
``tearDownModule`` are run.
Note that shared fixtures do not play well with [potential] features like test parallelization and they break test isolation. They should be used with care.
Note that shared fixtures do not play well with [potential] features like test
parallelization and they break test isolation. They should be used with care.
The default ordering of tests created by the unittest test loaders is to group all tests from the same modules and classes together. This will lead to ``setUpClass`` / ``setUpModule`` (etc) being called exactly once per class and module. If you randomize the order, so that tests from different modules and classes are adjacent to each other, then these shared fixture functions may be called multiple times in a single test run.
The default ordering of tests created by the unittest test loaders is to group
all tests from the same modules and classes together. This will lead to
``setUpClass`` / ``setUpModule`` (etc) being called exactly once per class and
module. If you randomize the order, so that tests from different modules and
classes are adjacent to each other, then these shared fixture functions may be
called multiple times in a single test run.
Shared fixtures are not intended to work with suites with non-standard ordering. A ``BaseTestSuite`` still exists for frameworks that don't want to support shared fixtures.
Shared fixtures are not intended to work with suites with non-standard
ordering. A ``BaseTestSuite`` still exists for frameworks that don't want to
support shared fixtures.
If there are any exceptions raised during one of the shared fixture functions the test is reported as an error. Because there is no corresponding test instance an ``_ErrorHolder`` object (that has the same interface as a :class:`TestCase`) is created to represent the error. If you are just using the standard unittest test runner then this detail doesn't matter, but if you are a framework author it may be relevant.
If there are any exceptions raised during one of the shared fixture functions
the test is reported as an error. Because there is no corresponding test
instance an ``_ErrorHolder`` object (that has the same interface as a
:class:`TestCase`) is created to represent the error. If you are just using
the standard unittest test runner then this detail doesn't matter, but if you
are a framework author it may be relevant.
setUpClass and tearDownClass
@ -1801,9 +1820,13 @@ These must be implemented as class methods::
def tearDownClass(cls):
cls._connection.destroy()
If you want the ``setUpClass`` and ``tearDownClass`` on base classes called then you must call up to them yourself. The implementations in :class:`TestCase` are empty.
If you want the ``setUpClass`` and ``tearDownClass`` on base classes called
then you must call up to them yourself. The implementations in
:class:`TestCase` are empty.
If an exception is raised during a ``setUpClass`` then the tests in the class are not run and the ``tearDownClass`` is not run. Skipped classes will not have ``setUpClass`` or ``tearDownClass`` run.
If an exception is raised during a ``setUpClass`` then the tests in the class
are not run and the ``tearDownClass`` is not run. Skipped classes will not
have ``setUpClass`` or ``tearDownClass`` run.
setUpModule and tearDownModule
@ -1817,6 +1840,7 @@ These should be implemented as functions::
def tearDownModule():
closeConnection()
If an exception is raised in a ``setUpModule`` then none of the tests in the module will be run and the ``tearDownModule`` will not be run.
If an exception is raised in a ``setUpModule`` then none of the tests in the
module will be run and the ``tearDownModule`` will not be run.