Fixed #32602 -- Clarified wording of TestCase class.

This commit is contained in:
faishalmanzar 2023-09-29 03:26:10 +05:30 committed by Mariusz Felisiak
parent e99c7d8847
commit f4e72e6523
7 changed files with 26 additions and 23 deletions

View File

@ -323,6 +323,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>

View File

@ -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)]

View File

@ -250,7 +250,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)

View File

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

View File

@ -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

View File

@ -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.

View File

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