From e9ed9ec043bca1ac93660029e0fa0376e1320375 Mon Sep 17 00:00:00 2001 From: Chiemezuo Date: Sun, 15 Dec 2024 09:43:17 +0100 Subject: [PATCH] Fixed #36008 -- Fixed order of database reset in TransactionTestCase docs. --- docs/topics/testing/tools.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt index 7830f5e575..dba2a9cce8 100644 --- a/docs/topics/testing/tools.txt +++ b/docs/topics/testing/tools.txt @@ -904,8 +904,8 @@ If your tests make any database queries, use subclasses ``TransactionTestCase`` inherits from :class:`~django.test.SimpleTestCase` to add some database-specific features: -* Resetting the database to a known state at the beginning of each test to - ease testing and using the ORM. +* Resetting the database to a known state at the end of each test to ease + testing and using the ORM. * Database :attr:`~TransactionTestCase.fixtures`. * Test :ref:`skipping based on database backend features `. * The remaining specialized :meth:`assert* @@ -914,7 +914,7 @@ add some database-specific features: Django's :class:`TestCase` class is a more commonly used subclass of ``TransactionTestCase`` that makes use of database transaction facilities to speed up the process of resetting the database to a known state at the -beginning of each test. A consequence of this, however, is that some database +end of each test. A consequence of this, however, is that some database behaviors cannot be tested within a Django ``TestCase`` class. For instance, you cannot test that a block of code is executing within a transaction, as is required when using @@ -1314,12 +1314,12 @@ by at least one test through ``databases``. However, a big part of the time taken to run a Django ``TestCase`` is consumed by the call to ``flush`` that ensures that you have a clean database at the -start of each test run. If you have multiple databases, multiple flushes are +end of each test run. If you have multiple databases, multiple flushes are required (one for each database), which can be a time consuming activity -- especially if your tests don't need to test multi-database activity. As an optimization, Django only flushes the ``default`` database at -the start of each test run. If your setup contains multiple databases, +the end of each test run. If your setup contains multiple databases, and you have a test that requires every database to be clean, you can use the ``databases`` attribute on the test suite to request extra databases to be flushed. @@ -1333,7 +1333,7 @@ For example:: call_some_test_code() This test case class will flush the ``default`` and ``other`` test databases -before running ``test_index_page_view``. You can also use ``'__all__'`` to +after 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