Speeding up Django Testing

Question

Im looking to learn more about your testing flows with Django.

Background information http://docs.djangoproject.com/en/dev/topics/testing/

Im encountering difficulties when using test driven development. The test runner of Django constantly creates all db models in a test db when starting. For our current projects (between 40 and 240 models) this means it takes easily 20s for tests to start.

This makes it completely unworkable for testing a new feature often. My question, how do you guys work around this?

I've tried a few things in the past a.) - change the testloader to reuse the same test db every time and apply migrations when needed b.) - run my unit tests from within the main flow of python files

option b is awkward with the sys.path, option a is doable but doesnt seem to be the django way.

Update: Option A is indeed not such a bad solution. Its just quite a bit of effort. Which makes me believe people use a different workaround. SQL lite could be that workaround. But im guessing there are more.

Answer 1

You can run only tests that interest you specyfically, look here: http://docs.djangoproject.com/en/dev/topics/testing/?from=olddocs#running-tests

Like in this example - run just specyfic TestCase:

$ ./manage.py test animals.AnimalTes

As for the test database - it is created and destroyed each time the test runs :( Also for testing you could use sqlite database if it is possible in your workflow.

Answer 2

Using an in-memory SQLite database during testing definitely speeds things up.

Answer 3

change the testloader to reuse the same test db every time and apply migrations when needed

(1) I don't see anything wrong in writing your own test runner that merely truncates the tables instead of dropping and creating the database. This is djangoic in that it solves a specific problem. There is a ticket open for allowing grouping of test cases into test suites. Once it is fixed you should be able to group your test cases into suites for easier management. You can also inspect the patch attached to the ticket and see if it will suit your purpose.

(2) As Ned suggested you can use an in memory database. This depends to a large extent on your data model and queries being portable across databases.

(3) If you haven't already try to reorganize your test cases. In my experience not all test classes need to sub class django.test.TestCase. Find out those test classes that can do with sub classing unittest.TestCase. This will speed up things a little bit.

(4) Reorganize fixtures. Move common fixtures to a single file and load it before the test run rather than inside each test class (using fixtures = [...]).