Changes between Version 3 and Version 4 of Ticket #20392, comment 22
- Timestamp:
- Nov 15, 2014, 8:06:24 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #20392, comment 22
v3 v4 5 5 * When `@override_settings` is decorating a `TestCase`, it should also affect `setUpClass` / `tearDownClass` 6 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)7 (EDIT: Handled in https://github.com/django/django/commit/d89f56dc4d03f6bf6602536b8b62602ec0d46d2f) 8 8 * Connections should no longer be closed after each test as a global `TestCase` transaction is maintained. 9 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 10 * If the database does not support transaction, `TestCase` will keep behaving as `TransactionTestCase`. 11 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). 12 (EDIT: I introduced a `setUpTestData` class method as suggested on https://groups.google.com/forum/#!topic/django-developers/deADv5ZaL6o so as to avoid this problem.) 12 13 13 14 14 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, MySQL (InnoDB) and Oracle. 15 16 17 I did those modifications in the branch https://github.com/tchaumeny/django/compare/use_setupclass. 15 18 16 19 In order to demonstrate the advantage of using `setUpClass`, I modified `select_related` and `queries` tests so that data are generated once in `setUpClass`: … … 34 37 OK (skipped=1, expected failures=2) 35 38 }}} 36 37 So, do you think it would be worthwhile to pursue in that direction ?