#20550 closed New feature (fixed)
Add an option to preserve the database between test runs
Reported by: | Aymeric Augustin | Owned by: | Greg Chapple |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | gregchapple1@…, mmanfre@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Creating database tables is expensive. #20483 says it takes 200s to create the tables required by Django's test suite with PostgreSQL. At $DAY_JOB, we have a few hundreds of models, and it takes about one minute to create a test database with PostgreSQL and a SSD.
To mitigate this problem, I've implemented a custom test runner that adds --nocreatedb
and --nodropdb
options to django-admin.py test
. The names are self-explanatory. I'm not going to publish the implementation because it's totally unsuitable for Django. (It monkey-patches BaseDatabaseCreation.create_test_db/destroy_test_db
when the flags are set.)
I'd like to implement a similar feature in Django. In the light of my first experience, I suggest a simpler API. I would add a single flag --keepdb
. When this flag is set:
- at the beginning of the tests, if the database already exists, Django doesn't ask to delete it; it goes ahead and reuses it;
- at the end of the tests, Django doesn't drop the database.
Change History (25)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|
I have the same use case as oinopion.
I wonder if there should be some safety net, that is a check that the used database is infact a test database, and that it contains at least somewhat up-to-date schema. The first is somewhat easy, create extra table on test database setup, say 'django_test_meta' or something like that. If it exists, then the DB is assumed to be a test database.
The second issue is a lot harder. It would be extremely convenient if the test runner could detect stale databases and recreate the test database if needed. Something like storing md5 checksum of the model setup per app. A lighter check could be to check that all tables for managed models exists, and maybe that all columns (without datatype check) exists, too.
Both of the additions are in the category "nice to have", not blockers for commit.
comment:3 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 11 years ago
I just found my original implementation for this feature: https://gist.github.com/aaugustin/3012318
As said in the original description, I think we can improve the API.
comment:5 by , 11 years ago
aaugustin, thanks for this. I haven't had a huge amount of time to work on this lately, just getting bits here and there. This is very helpful though, thanks!
comment:6 by , 11 years ago
Has patch: | set |
---|---|
Patch needs improvement: | set |
I've created a pull request for this: https://github.com/django/django/pull/2726
There is one failing test, however, and I'm not exactly sure why it is failing. If anyone can give some feedback / insight on it that would be great!
Thanks!
comment:7 by , 11 years ago
Patch needs improvement: | unset |
---|
Ignore previous comment. I figured out why it was failing. I've updated the pull request, all tests passing.
comment:10 by , 10 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
LGTM; will let Aymeric do a final review.
comment:11 by , 10 years ago
Cc: | added |
---|
comment:12 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:16 by , 10 years ago
Greg, next time you submit a patch, please add yourself to AUTHORS! (Sorry, I never remember to check that before merging patches.)
comment:18 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
Triage Stage: | Ready for checkin → Accepted |
Re-opening this per a discussion on IRC where it was highlighted that BaseDatabaseCreation.create_test_db
receives the new keepdb
option, but BaseDatabaseCreation.destroy_test_db
(and subclasses) do not, which leaves a strange asymmetry.
I'm putting together a patch for this now.
comment:19 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:20 by , 10 years ago
Cc: | added |
---|
comment:22 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I see another benefit of that: At {{ day_job }} we have database that can't be easily recreated by syncdb (it is used by other apps, too). Moreover, due to permissions we can't create and drop db on CI server. We currently we override
setup_database
andteardown_database
to disable creation and deletion of test db altogether.