mirror of https://github.com/django/django.git
Fixed #32602 -- Clarified wording of TestCase class.
This commit is contained in:
parent
e99c7d8847
commit
f4e72e6523
1
AUTHORS
1
AUTHORS
|
@ -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>
|
||||
|
|
|
@ -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)]
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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::
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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):
|
||||
|
|
Loading…
Reference in New Issue