17

Running Django unit tests is far too slow. Especially when I just want to run one test but the test runner wants to create the entire database and destroy the whole thing just for that one test.

In the case where I have not changed any of my models, I could save oodles of time if Django would not bother trying to create and destroy the entire database, and instead saved it for next time. Better yet, it would be great if the test runner was capable of being able to see which models have changed and only replacing those prior to running tests.

I'd prefer to not have to subclass the test runner myself, but that's what I'm going to have to do if I don't find a solution soon. is there anything like this already in existence?

Conley Owens
  • 8,691
  • 5
  • 30
  • 43

3 Answers3

22

In django1.8 added new parameter for manage.py test command --keepdb

./manage.py test --keepdb
Patrick Z
  • 2,119
  • 1
  • 16
  • 10
4

Have you tried using an in-memory SQLite database for tests? It's much faster than using a disk-based database.

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
  • Last time I tried, spatialite wasn't playing nicely on whatever version of ubuntu I was using, so I quickly abandoned that. I should try it again now though. – Conley Owens Jun 28 '10 at 04:57
  • 3
    I think it is necessary to run the tests on the same database, as you use in live, if not always, atleast before every commit. – lprsd Jul 01 '10 at 13:14
  • Caution: SQLite3 currently does NOT work multi-threaded, so if you have any (integration) tests which rely on / test concurrent access to the DB, they will give grief. – JohnJ Jul 29 '13 at 19:04
1

I'm using Djang-nose. If you set a env var REUSE_DB=1 it will not destroy the DB after running tests and re-use that same DB for the next run. Whenever your schema changes, just set REUSE_DB=0 and do one 'full' run. After that reset it to 1 and you're good to go.

https://github.com/django-nose/django-nose

gterzian
  • 535
  • 6
  • 5