On Saturday, October 23, 2010, Phlip <phlip2...@gmail.com> wrote: > Djangoists: > > My last project got into trouble because the .json test fixtures took > so bloody long to run. (I fussed about that here at the time...) > > So I started my current, blue-sky project with an absolutely clean new > codebase, and Django 1.2.3. I switched the test database to SQLite, > and wrote unit tests by creating each sample model object in the > setUp(). > > Tests took 1.25s to run. > > When I dumped out that database as .json, and switched from using > setUp() to using fixtures, tests went to 1.45s. > > This bodes ill for bigger data sets.
If a single fixture takes more than a second to load, i would suggest to you that the problem lies in your test case. Tests should be as simple as possible. Huge fixture files suggests to me that the first port of call should be to try and simplify your test case and reduce the size of your fixture file. That said, if anyone can suggest any optimizations to the fixture loading process (or any other part of Django for that matter) we're happy to look at integrating those changes. > Is there some way to determine if the test runner is indeed using the > transaction-rollback trick? Where it creates the DB once, puts each > test case inside a transaction, and rolls the transaction back after > each run? If you use django.test.TestCase, the rollback behavior will be used. If you use a TransactionTestCase, tables will be flushed. There is no other special logic or condition that you need to test for. The only exception to this is when your database doesn't support transactions (which effectively means MySQL MyISAM), in which case all tests become TransactionTestCases. > (Also, is there some way to log every SQL command sent to the DB?) Yes; connection.queries contains a list of the executed SQL statements. If you're running Django trunk, the recently added logging framework includes a hook for outputting every SQL statement to a log handler. However, both these utilities are only available when debug is enabled. > And even if the fixtures were re-creating the database before each > test case, shouldn't that work at the same speed as manual creation? > How on earth could it be slower?? I would be amazed if fixture loading was faster than manual creation. Fixtures don't magically parse themselves. Parsing takes time, and then the objects still have to be created. Unless your manual creation code contains some seriously pathological logic, manual creation will *always* be faster. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
