mirror of
https://github.com/django/django.git
synced 2025-10-31 09:41:08 +00:00
Fixed #18271 -- Changed stage at which TransactionTestCase flushes DB tables.
Previously, the flush was done before the test case execution and now it is performed after it. Other changes to the testing infrastructure include: * TransactionTestCase now doesn't reset autoincrement sequences either (previous behavior can achieved by using `reset_sequences`.) With this, no implicit such reset is performed by any of the provided TestCase classes. * New ordering of test cases: All unittest tes cases are run first and doctests are run at the end. THse changes could be backward-incompatible with test cases that relied on some kind of state being preserved between tests. Please read the relevant sections of the release notes and testing documentation for further details. Thanks Andreas Pelme for the initial patch. Karen Tracey and Anssi Kääriäinen for the feedback and Anssi for reviewing. This also fixes #12408.
This commit is contained in:
@@ -188,6 +188,57 @@ Session not saved on 500 responses
|
||||
Django's session middleware will skip saving the session data if the
|
||||
response's status code is 500.
|
||||
|
||||
Changes in tests execution
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some changes have been introduced in the execution of tests that might be
|
||||
backward-incompatible for some testing setups:
|
||||
|
||||
Database flushing in ``django.test.TransactionTestCase``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Previously, the test database was truncated *before* each test run in a
|
||||
:class:`~django.test.TransactionTestCase`.
|
||||
|
||||
In order to be able to run unit tests in any order and to make sure they are
|
||||
always isolated from each other, :class:`~django.test.TransactionTestCase` will
|
||||
now reset the database *after* each test run instead.
|
||||
|
||||
No more implict DB sequences reset
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
:class:`~django.test.TransactionTestCase` tests used to reset primary key
|
||||
sequences automatically together with the database flushing actions described
|
||||
above.
|
||||
|
||||
This has been changed so no sequences are implicitly reset. This can cause
|
||||
:class:`~django.test.TransactionTestCase` tests that depend on hard-coded
|
||||
primary key values to break.
|
||||
|
||||
The new :attr:`~django.test.TransactionTestCase.reset_sequences` attribute can
|
||||
be used to force the old behavior for :class:`~django.test.TransactionTestCase`
|
||||
that might need it.
|
||||
|
||||
Ordering of tests
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
In order to make sure all ``TestCase`` code starts with a clean database,
|
||||
tests are now executed in the following order:
|
||||
|
||||
* First, all unittests (including :class:`unittest.TestCase`,
|
||||
:class:`~django.test.SimpleTestCase`, :class:`~django.test.TestCase` and
|
||||
:class:`~django.test.TransactionTestCase`) are run with no particular ordering
|
||||
guaranteed nor enforced among them.
|
||||
|
||||
* Then any other tests (e.g. doctests) that may alter the database without
|
||||
restoring it to its original state are run.
|
||||
|
||||
This should not cause any problems unless you have existing doctests which
|
||||
assume a :class:`~django.test.TransactionTestCase` executed earlier left some
|
||||
database state behind or unit tests that rely on some form of state being
|
||||
preserved after the execution of other tests. Such tests are already very
|
||||
fragile, and must now be changed to be able to run independently.
|
||||
|
||||
Miscellaneous
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
|
||||
Reference in New Issue
Block a user