mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-12-23 09:19:18 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

[3.14] gh-101100: Fix sphinx warnings in library/unittest.rst (GH-140109) (#141853)

Browse source 
Co-authored-by: Weilin Du <108666168+LamentXU123@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
This commit is contained in:
Miss Islington (bot) 2025-11-22 20:23:59 +01:00 • committed by GitHub
parent 972aa93692
commit 5755ce0a87
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 25 additions and 26 deletions
Download patch file Download diff file Expand all files Collapse all files

50
Doc/library/unittest.rst
View file

@ -438,7 +438,7 @@ run whether the test method succeeded or not.
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
@ -518,7 +518,7 @@ set-up and tear-down methods::
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.
@ -1023,7 +1023,7 @@ Test cases
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:
@ -1036,7 +1036,7 @@ Test cases
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.
@ -1089,8 +1089,8 @@ Test cases
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::
@ -1430,7 +1430,7 @@ Test cases
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
@ -1638,7 +1638,7 @@ Test cases
.. 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
@ -1648,7 +1648,7 @@ Test cases
: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
@ -1677,7 +1677,7 @@ Test cases
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.
@ -1798,7 +1798,7 @@ Grouping tests
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
@ -1809,10 +1809,10 @@ Grouping tests
.. 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
@ -1846,12 +1846,12 @@ 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.
@ -1898,13 +1898,13 @@ Loading and running tests
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.
@ -2051,7 +2051,7 @@ Loading and running tests
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:
@ -2137,12 +2137,12 @@ Loading and running 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
@ -2462,9 +2462,9 @@ 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.
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

1
Doc/tools/.nitignore
View file

@ -36,7 +36,6 @@ Doc/library/tkinter.rst
Doc/library/tkinter.scrolledtext.rst
Doc/library/tkinter.ttk.rst
Doc/library/unittest.mock.rst
Doc/library/unittest.rst
Doc/library/urllib.parse.rst
Doc/library/urllib.request.rst
Doc/library/wsgiref.rst