Just a quick FYI - https://groups.google.com/forum/#!msg/django-developers/N0HEAD1ht8k/GQJ77RLUydsJ
I tried to implement fixture loading in setupClass() and ran into a few difficulties. I did a lot of profiling though. You get about a factor of 3 speedup for tests that use fixtures. It only represents about 10% of the entire test run though (which is still a great speedup). There may be some ideas in the patch linked to in the above thread that you could use. +1 from me too. It would be great to speed up the test suite. On Monday, 10 November 2014 17:14:32 UTC+11, Anssi Kääriäinen wrote: > > On Sun, 2014-11-09 at 16:19 -0800, Thomas wrote: > > > In order to make the whole Django test suite pass with that change, I > > had to adapt a bunch of tests. I described the technical issues in > > https://code.djangoproject.com/ticket/20392#comment:22 but the main > > problem is due to some tests in Django test suite relying on the fact > > that a new database connection is generated after each test, which is > > a behaviour that should change if we want to maintain a transaction at > > TestCase level. I don't know if a lot of TestCase out of Django test > > suite rely on that behavior (for instance, Django relies on that in a > > test which closes the connection explicitely) and those tests should > > work if turned into TransactionTestCase. > > > > Another issue I can think of is that if people start refactoring their > > tests to create initial data in setUpClass, the refactored tests will > > generate data that will leak between TestCase when run on a database > > which does not support transactions (e.g. MySQL with MyISAM engine). > > It might be better to go with setupTestData() method. On MySQL + MyISAM > this is ran before every test. Similar for TransactionTestCase. For > those databases that do fully support atomic() the setup is ran just > once for each test class. > > By the way I believe there is an additional speedup to be achieved here > - we can also load fixture data once per test class, and that should > give a significant speedup for tests that rely on fixture data. You > could check this with aggregation, aggregation_regress and admin test > modules. > > > So, do you think it's worth implementing that despite the possible > > incompatibilities ? Do you see any other issue ? > > +1 from me. > > - Anssi > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8a3cecdf-3b42-4e61-b85b-a0fb01ad9790%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
