Black 23.1.0 is released which, as the first release of the year,
introduces the 2023 stable style. This incorporates most of last year's
preview style.
https://github.com/psf/black/releases/tag/23.1.0
"test --shuffle" skipped test methods when test classes were mixed.
This changes runner.py's reorder_tests() to group by TestCase class.
Regression in 90ba716bf0.
This also makes partition_suite_by_type(), partition_suite_by_case(),
filter_tests_by_tags(), and DiscoverRunner._get_databases() to use
iter_test_cases().
Whether or not the state of a test database should be serialized can be
inferred from the set of databases allowed to be access from discovered
TestCase/TransactionTestCase enabling the serialized_rollback feature
which makes this setting unnecessary.
This should make a significant test suite bootstraping time difference
on large projects that didn't explicitly disable test database
serialization.
This fixes flushing test databases when two aliases point to the same
database.
Use a list() to store the test database aliases so the order remains
stable by following the order of the connections. Also, always use the
"default" database alias as the first alias to accommodate `migrate`.
Previously `migrate` could be executed on a secondary alias which
caused truncating the "default" database.
Use tempfile.TemporaryDirectory() in AdminScriptTestCase.setUp()
to create and destroy a temporary directory for each test. It removes
the need for individual tests to delete files.
For test classes that don't use the temporary directory, inherit from
SimpleTestCase.
The test was expecting connections used by DiscoverRunner.setup_databases()
to be the ones defined in django.test.runner but this doesn't hold true
since this method was made a proxy of django.test.utils.setup_databases.
This broke the TransactionTestCase.serialized_rollback feature in the test
suite because calls to create_db_test() cleared the test data persisted on
connections objects.
Added an assertions to prevent this from happening again.
Prior to this change foreign key constraint references could be left pointing
at tables dropped during operations simulating unsupported table alterations
because of an unexpected failure to disable foreign key constraint checks.
SQLite3 does not allow disabling such checks while in a transaction so they
must be disabled beforehand.
Thanks ezaquarii for the report and Carlton and Tim for the review.
