mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2024-12-22 09:05:43 +00:00
Code Issues 25 Releases Wiki Activity

Fixed #36008 -- Fixed order of database reset in TransactionTestCase docs.

Browse Source
This commit is contained in:
Chiemezuo 2024-12-15 09:43:17 +01:00 committed by Sarah Boyce
parent 47eafd139b
commit e9ed9ec043
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/topics/testing/tools.txt
View File

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