[5.0.x] Fixed #32602 -- Clarified wording of TestCase class.

Backport of f4e72e6523e6968d9628dfbff914ab57dbf19e6b from main

3 files changed, 16 insertions, 14 deletions

diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index 54b9d7d133..388ffd696d 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -570,9 +570,10 @@ and tear down the test suite.
 
     ``parallel`` specifies the number of processes.  If ``parallel`` is greater
     than ``1``, the test suite will run in ``parallel`` processes. If there are
-    fewer test cases than configured processes, Django will reduce the number
-    of processes accordingly. Each process gets its own database. This option
-    requires the third-party ``tblib`` package to display tracebacks correctly.
+    fewer test case classes than configured processes, Django will reduce the
+    number of processes accordingly. Each process gets its own database. This
+    option requires the third-party ``tblib`` package to display tracebacks
+    correctly.
 
     ``tags`` can be used to specify a set of :ref:`tags for filtering tests
     <topics-tagging-tests>`. May be combined with ``exclude_tags``.
@@ -690,7 +691,7 @@ Methods
     label can take one of four forms:
 
     * ``path.to.test_module.TestCase.test_method`` -- Run a single test method
-      in a test case.
+      in a test case class.
     * ``path.to.test_module.TestCase`` -- Run all the test methods in a test
       case.
     * ``path.to.module`` -- Search for and run all tests in the named Python
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index 5dbe46ceb2..a312d24dd1 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -41,9 +41,10 @@ transaction to provide isolation::
             self.assertEqual(cat.speak(), 'The cat says "meow"')
 
 When you :ref:`run your tests <running-tests>`, the default behavior of the
-test utility is to find all the test cases (that is, subclasses of
+test utility is to find all the test case classes (that is, subclasses of
 :class:`unittest.TestCase`) in any file whose name begins with ``test``,
-automatically build a test suite out of those test cases, and run that suite.
+automatically build a test suite out of those test case classes, and run that
+suite.
 
 For more details about :mod:`unittest`, see the Python documentation.
 
@@ -98,7 +99,7 @@ path to a package, module, ``TestCase`` subclass, or test method. For instance:
     # Run all the tests found within the 'animals' package
     $ ./manage.py test animals
 
-    # Run just one test case
+    # Run just one test case class
     $ ./manage.py test animals.tests.AnimalTestCase
 
     # Run just one test method
@@ -223,7 +224,7 @@ the Django test runner reorders tests in the following way:
 
 * All :class:`~django.test.TestCase` subclasses are run first.
 
-* Then, all other Django-based tests (test cases based on
+* Then, all other Django-based tests (test case classes based on
   :class:`~django.test.SimpleTestCase`, including
   :class:`~django.test.TransactionTestCase`) are run with no particular
   ordering guaranteed nor enforced among them.
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index a9373ff108..a415097c56 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -1231,8 +1231,8 @@ Fixture loading
 
 .. attribute:: TransactionTestCase.fixtures
 
-A test case for a database-backed website isn't much use if there isn't any
-data in the database. Tests are more readable and it's more maintainable to
+A test case class for a database-backed website isn't much use if there isn't
+any data in the database. Tests are more readable and it's more maintainable to
 create objects using the ORM, for example in :meth:`TestCase.setUpTestData`,
 however, you can also use :ref:`fixtures <fixtures-explanation>`.
 
@@ -1327,9 +1327,9 @@ For example::
         def test_index_page_view(self):
             call_some_test_code()
 
-This test case will flush the ``default`` and ``other`` test databases before
-running ``test_index_page_view``. You can also use ``'__all__'`` to specify
-that all of the test databases must be flushed.
+This test case class will flush the ``default`` and ``other`` test databases
+before running ``test_index_page_view``. You can also use ``'__all__'`` to
+specify that all of the test databases must be flushed.
 
 The ``databases`` flag also controls which databases the
 :attr:`TransactionTestCase.fixtures` are loaded into. By default, fixtures are
@@ -1965,7 +1965,7 @@ you might label fast or slow tests::
         def test_slow_but_core(self):
             ...
 
-You can also tag a test case::
+You can also tag a test case class::
 
     @tag("slow", "core")
     class SampleTestCase(TestCase):