diff options
| author | Gregory P. Smith <greg@krypto.org> | 2018-05-17 15:08:45 (GMT) |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-05-17 15:08:45 (GMT) |
| commit | dff46758f267ad6c13096c69c4e1dee17f9969aa (patch) | |
| tree | 4649e6d5110c57283e17999334b9eabace345a24 /Doc | |
| parent | 3ab0136ac5d6059ce96d4debca89c5f5ab0356f5 (diff) | |
| download | cpython-dff46758f267ad6c13096c69c4e1dee17f9969aa.zip cpython-dff46758f267ad6c13096c69c4e1dee17f9969aa.tar.gz cpython-dff46758f267ad6c13096c69c4e1dee17f9969aa.tar.bz2 | |
bpo-19950: Clarify unittest TestCase instance use. (GH-6875)
Diffstat (limited to 'Doc')
| -rw-r--r-- | Doc/library/unittest.rst | 24 |
1 files changed, 15 insertions, 9 deletions
diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst index af71be4..086d937 100644 --- a/Doc/library/unittest.rst +++ b/Doc/library/unittest.rst @@ -361,8 +361,9 @@ testing code:: Note that in order to test something, we use one of the :meth:`assert\*` methods provided by the :class:`TestCase` base class. If the test fails, an -exception will be raised, and :mod:`unittest` will identify the test case as a -:dfn:`failure`. Any other exceptions will be treated as :dfn:`errors`. +exception will be raised with an explanatory message, and :mod:`unittest` +will identify the test case as a :dfn:`failure`. Any other exceptions will be +treated as :dfn:`errors`. Tests can be numerous, and their set-up can be repetitive. Luckily, we can factor out set-up code by implementing a method called @@ -408,13 +409,18 @@ after the test method has been run:: If :meth:`~TestCase.setUp` succeeded, :meth:`~TestCase.tearDown` will be run whether the test method succeeded or not. -Such a working environment for the testing code is called a :dfn:`fixture`. - -Test case instances are grouped together according to the features they test. -:mod:`unittest` provides a mechanism for this: the :dfn:`test suite`, -represented by :mod:`unittest`'s :class:`TestSuite` class. In most cases, -calling :func:`unittest.main` will do the right thing and collect all the -module's test cases for you, and then execute them. +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 +`~TestCase.setUp`, `~TestCase.tearDown`, and `~TestCase.__init__` +will be called once per test. + +It is recommended that you use TestCase implementations to group tests together +according to the features they test. :mod:`unittest` provides a mechanism for +this: the :dfn:`test suite`, represented by :mod:`unittest`'s +:class:`TestSuite` class. In most cases, calling :func:`unittest.main` will do +the right thing and collect all the module's test cases for you and execute +them. However, should you want to customize the building of your test suite, you can do it yourself:: |