diff --git a/AUTHORS b/AUTHORS index a633f6e03c2a..2a331e4818fc 100644 --- a/AUTHORS +++ b/AUTHORS @@ -323,6 +323,7 @@ answer newbie questions, and generally made Django that much better: Evan Grim Fabian Büchler Fabrice Aneche + Faishal Manzar Farhaan Bukhsh favo@exoweb.net fdr diff --git a/django/test/runner.py b/django/test/runner.py index eb3cea19590e..ecd10d5d9168 100644 --- a/django/test/runner.py +++ b/django/test/runner.py @@ -498,9 +498,9 @@ def __init__( 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)] diff --git a/django/test/testcases.py b/django/test/testcases.py index 60a04bf5d2f2..391b5e99ccd4 100644 --- a/django/test/testcases.py +++ b/django/test/testcases.py @@ -250,7 +250,7 @@ def _remove_databases_failures(cls): 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) diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index eb77e2a17d4e..86cac790faaa 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 fda77e766197..6f3f54e34129 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 `. 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 30f4a75edc02..6caa1ab131eb 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 `, 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 4eaffdb3316a..16cc7759b35e 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 `. @@ -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):