diff options
| author | Chiemezuo <chiemezuoakujobi@gmail.com> | 2024-12-15 09:43:17 +0100 |
|---|---|---|
| committer | Sarah Boyce <42296566+sarahboyce@users.noreply.github.com> | 2024-12-16 13:12:48 +0100 |
| commit | e9ed9ec043bca1ac93660029e0fa0376e1320375 (patch) | |
| tree | d55067b86577b8fc40c528016cf83ad92bab0a14 /docs | |
| parent | 47eafd139bf5ffafd41cdde40e6645165c92e297 (diff) | |
Fixed #36008 -- Fixed order of database reset in TransactionTestCase docs.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/topics/testing/tools.txt | 12 |
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 |
