Changes between Version 3 and Version 4 of Ticket #20392, comment 22


Ignore:
Timestamp:
Nov 15, 2014, 8:06:24 AM (10 years ago)
Author:
Thomas C

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #20392, comment 22

    v3 v4  
    55* When  `@override_settings` is decorating a `TestCase`, it should also affect `setUpClass` / `tearDownClass`
    66There 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)
    88* Connections should no longer be closed after each test as a global `TestCase` transaction is maintained.
    99Some 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.
    1010* If the database does not support transaction, `TestCase` will keep behaving as `TransactionTestCase`.
    1111This 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.)
    1213
    1314
    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
     17I did those modifications in the branch https://github.com/tchaumeny/django/compare/use_setupclass.
    1518
    1619In order to demonstrate the advantage of using `setUpClass`, I modified `select_related` and `queries` tests so that data are generated once in `setUpClass`:
     
    3437OK (skipped=1, expected failures=2)
    3538}}}
    36 
    37 So, do you think it would be worthwhile to pursue in that direction ?
Back to Top