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