Re: Long-running tests

On Apr 17, 2:58 am, Paul McMillan wrote: > For the particular test case in modeltests/fixtures/models.py, we > might be able to improve test time by tearing the fixtures down after > verifying them, rather than doing a full flush. This will be easier to > do after converting

Re: Long-running tests

I'm hoping to be able to help with this problem during the SoC. In particular, I'm hoping that we can integrate unittest2 to make skipping these long-running tests easier. > And I know why. There are 10 of these: > >>> management.call_command('flush', verbosity=0, interactive=False

Re: Long-running tests

On Fri, Apr 16, 2010 at 11:00 PM, Tom X. Tobin wrote: > [snip details of run times] > > Sticking out like a sore thumb is API_TESTS under > modeltests.fixtures.models.__test__, which clocks in at 1090 > seconds(!). The serializer tests also seem to take a pretty chunk of

Long-running tests

I recently noticed that the Django test suite seemed to be ballooning in run time, so I wrote a new test runner that tracked run times. I set it to emit run times longer than two seconds, and had the following results (under PostgresSQL, since that's what we use in production): ** Long