summaryrefslogtreecommitdiff
path: root/docs/topics/testing/tools.txt
diff options
context:
space:
mode:
authorChiemezuo <chiemezuoakujobi@gmail.com>2024-12-15 09:43:17 +0100
committerSarah Boyce <42296566+sarahboyce@users.noreply.github.com>2024-12-16 13:12:48 +0100
commite9ed9ec043bca1ac93660029e0fa0376e1320375 (patch)
treed55067b86577b8fc40c528016cf83ad92bab0a14 /docs/topics/testing/tools.txt
parent47eafd139bf5ffafd41cdde40e6645165c92e297 (diff)
Fixed #36008 -- Fixed order of database reset in TransactionTestCase docs.
Diffstat (limited to 'docs/topics/testing/tools.txt')
-rw-r--r--docs/topics/testing/tools.txt12
1 files 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 <skipping-tests>`.
* 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