Changes between Initial Version and Version 1 of Ticket #20392, comment 22
- Timestamp:
- Oct 19, 2014, 9:38:33 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #20392, comment 22
initial v1 7 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 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 ìnspectdb` and `introspection`) to use `TransactionTestCase` instead of `TestCase` to make the test suite pass with MySQL. 9 10 10 I did those modifications in my branch https://github.com/tchaumeny/django/compare/use_setupclass, and the django test suite is passing with both PostgreSQL and SQLite — I still need to test with MySQL (InnoDB mode) but run into some unrelated issues.11 I did those modifications in the branch https://github.com/tchaumeny/django/compare/use_setupclass, and the django test suite is now passing with PostgreSQL, SQLite and MySQL (InnoDB). 11 12 12 13 In order to demonstrate the advantage of using `setUpClass`, I modified `select_related` and `queries` tests so that data are generated once in `setUpClass`: