| 5 | | * When `@override_settings` is decorating a `TestCase` it should also affect `setUpClass` / `tearDownClass` |
| 6 | | => There already is a ticket for that (#21281), but I believe it is required if we are going to tell people they can interact with the database within `setUpClass` as the result of that interaction might depend on whether or not the settings were overridden when it happened (`USE_TZ` for instance). |
| 7 | | * Connections should no longer be closed after each test within a `TestCase`. This was already part of the initial proposal and might be considered as a backward incompatible change as some tests purposely generate database failures or even close the connection explicitly. Those tests should use `TransactionTestCase` instead — in Django test suite, some threading tests in `django/tests/backends` are concerned. |
| 8 | | * If the database does not support transaction, `TestCase` will keep behaving as `TransactionTestCase`. This means that initializing data within `setUpClass` will result in random behavior. This is the current behavior hence should not be considered as a backward incompatible change, but it means that tests refactored to take advantage of `setUpClass` (which might be very interesting, see below) should not run under MySQL with MyISAM (no transaction support). |
| 9 | | * Some backends do not support rollbacking statements altering the structure of tables (backends with `can_rollback_ddl = False`, currently MySQL and Oracle). I had to modify two tests cases (in `inspectdb` and `introspection`) to use `TransactionTestCase` instead of `TestCase` to make the test suite pass with MySQL. |
| | 5 | * When `@override_settings` is decorating a `TestCase`, it should also affect `setUpClass` / `tearDownClass` |
| | 6 | There already is a ticket for that (#21281), but I believe it is required if we are going to tell people they can interact with the database within `setUpClass` as the result of that interaction might depend on whether or not the settings were overridden when it happened (`USE_TZ` for instance). |
| | 7 | (EDIT: this has been changed in https://github.com/django/django/commit/d89f56dc4d03f6bf6602536b8b62602ec0d46d2f) |
| | 8 | * Connections should no longer be closed after each test as a global `TestCase` transaction is maintained. |
| | 9 | Some tests in Django test suite (e.g. `django/tests/backends`) generate database failures and implicitely rely on a new connection being created for each test, one test even close the connection explicitely. I also run into a bunch of failures under Oracle and MySQL, because those backends fail when rollbacking a transaction altering the structure of a table (see `can_rollback_ddl = False`). Those failures were hidden because the connection was always closed afterwards. I turned those tests into `TransactionTestCase` and made some adaptation when required. |
| | 10 | * If the database does not support transaction, `TestCase` will keep behaving as `TransactionTestCase`. |
| | 11 | This behaviour is unchanged, but it means that tests refactored to take advantage of `setUpClass` should not run under MySQL with MyISAM (no transaction support). |