Fixed #32602 -- Clarified wording of TestCase class.

4 files changed, 21 insertions, 19 deletions

diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index eb77e2a17d..86cac790fa 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -1477,12 +1477,12 @@ override this by passing the desired number of processes, e.g.
 variable.
 
 Django distributes test cases — :class:`unittest.TestCase` subclasses — to
-subprocesses. If there are fewer test cases than configured processes, Django
-will reduce the number of processes accordingly.
+subprocesses. If there are fewer test case classes than configured processes,
+Django will reduce the number of processes accordingly.
 
-Each process gets its own database. You must ensure that different test cases
-don't access the same resources. For instance, test cases that touch the
-filesystem should create a temporary directory for their own use.
+Each process gets its own database. You must ensure that different test case
+classes don't access the same resources. For instance, test case classes that
+touch the filesystem should create a temporary directory for their own use.
 
 .. note::
 
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index fda77e7661..6f3f54e341 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -562,9 +562,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``.
@@ -682,7 +683,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 30f4a75edc..6caa1ab131 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 4eaffdb331..16cc7759b3 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -1195,8 +1195,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>`.
 
@@ -1291,9 +1291,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
@@ -1925,7 +1925,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):