unittest documentation formatting changes

1 files changed, 37 insertions, 13 deletions

diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst
index c15e6e2..ec091ab 100644
--- a/Doc/library/unittest.rst
+++ b/Doc/library/unittest.rst
@@ -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.