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

Backport of f4e72e6523e6968d9628dfbff914ab57dbf19e6b from main

AUTHORS

@@ -322,6 +322,7 @@ answer newbie questions, and generally made Django that much better:
     Evan Grim <https://github.com/egrim>
     Fabian Büchler <fabian.buechler@inoqo.com>
     Fabrice Aneche <akh@nobugware.com>
+    Faishal Manzar <https://github.com/faishal882>
     Farhaan Bukhsh <farhaan.bukhsh@gmail.com>
     favo@exoweb.net
     fdr <drfarina@gmail.com>

django/test/runner.py

@@ -498,9 +498,9 @@ class ParallelTestSuite(unittest.TestSuite):
 
     def run(self, result):
         """
-        Distribute test cases across workers.
+        Distribute TestCases across workers.
 
-        Return an identifier of each test case with its result in order to use
+        Return an identifier of each TestCase with its result in order to use
         imap_unordered to show results as soon as they're available.
 
         To minimize pickling errors when getting results from workers:
@@ -1204,7 +1204,7 @@ def reorder_tests(tests, classes, reverse=False, shuffler=None):
 
 
 def partition_suite_by_case(suite):
-    """Partition a test suite by test case, preserving the order of tests."""
+    """Partition a test suite by TestCase, preserving the order of tests."""
     suite_class = type(suite)
     all_tests = iter_test_cases(suite)
     return [suite_class(tests) for _, tests in itertools.groupby(all_tests, type)]

django/test/testcases.py

@@ -252,7 +252,7 @@ class SimpleTestCase(unittest.TestCase):
     def __call__(self, result=None):
         """
         Wrapper around default __call__ method to perform common Django test
-        set up. This means that user-defined Test Cases aren't required to
+        set up. This means that user-defined TestCases aren't required to
         include a call to super().setUp().
         """
         self._setup_and_call(result)

docs/ref/django-admin.txt

@@ -1484,12 +1484,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::
 

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

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.

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):