On Thursday 3 May 2012 at 19:23, Anssi Kääriäinen wrote: > On May 3, 7:29 pm, Andreas Pelme <andr...@pelme.se (http://pelme.se)> wrote: > > I am trying to run my Django test suite with an alternative test runner > > (py.test), and found some issues with test isolation. > > > > TransactionTestCase does currently not clean up after itself (i.e. flush > > the database), but instead assumes that the next test will flush the > > database. It is generally a good idea to restore the state after the test > > run, and let other tests start out with a known state. > > > > Djangos default testrunner reorders the test suite to run all TestCase > > tests before TransactionTestCases, which avoids this problem. I cannot find > > this reordering documented anywhere, or even commented anywhere in the > > implementation (test/simple.py: reorder_suite and > > DjangoTestSuiteRunner.build_suite). > > > > I propose to move the flush command out of _fixture_setup to _post_teardown > > in TransactionTestCase. This makes it possible for arbitrary execution > > order of the test suite. Performance could potentially be an issue, since > > it is "lazy" today and flushes the database just right before it is needed. > > That would however only affect the last test in the run (i.e. it will > > truncate the tables, and then the database itself will be teared down). > > > > Are there any objections or anything that might break with such a change? > > Are there any specific reasons it works the way it does? > > I don't know if anything will break... > > I think this is a good idea. In addition to the above issues this > would allow the test ran tell the flushing which tables are dirty, > which not. Currently the transaction_regress for example uses just a > single table. But after each test, all tables will be truncated, and > the contenttypes and permissions will be reloaded. I bet we could > speed up the testing _a lot_ if the cleaning up could be made more > intelligent. Making it robust is somewhat hard but should not be > impossible. Of course, the "StateTrackingTestCase" should not be done > in the same patch at all... just a possibility for future work.
There are indeed some work that can be done to speed up the test running. :) Here's the ticket: https://code.djangoproject.com/ticket/18271 … and an initial patch: https://github.com/django/django/pull/45 Is there any sane way to test this except to run the test suite itself? Andreas -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
