Opened 11 years ago
Last modified 8 years ago
#21742 new New feature
Unable to prevent creation of a database during test runs
Reported by: | yscumc | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I have two databases set up as follows:
DATABASES = { 'default': { ... }, 'someotherdb': { ... }, }
I do not have write access to someotherdb
and would like to prevent the creation of a test database for someotherdb
when my tests run. However, this simple scenario doesn't seem to be possible.
I believe Django would would greatly benefit from having another option for the database dict such as the following:
DATABASES = { 'default': { ... }, 'someotherdb': { ... 'TEST_CREATE_DATABASE': False, }, }
If set, DjangoTestSuiteRunner.setup_databases()
and DjangoTestSuiteRunner.teardown_databases()
should delete the database from the django.db.connections
so it cannot be accessed from the unit tests. It should prevent an error from being raised upon trying to run test cases which do not use the read-only database.
In an attempted workaround, subclassing DjangoTestSuiteRunner
as in http://stackoverflow.com/questions/5917587/django-unit-tests-without-a-db doesn't work because I need to use the default
database in my test. Using this method, if I want to use the default
database, but not someotherdb
, I would probably have to copy and paste most of the code from DjangoTestSuiteRunner.setup_databases()
even after subclasssing DjangoTestSuiteRunner
. It also doesn't make sense to have to do all this just to prevent a test database from being created.
I then tried the following, but it doesn't seem to work because of perhaps a pesky bug:
DATABASES = { 'default': { 'NAME': 'mydefaultdb', ... }, 'someotherdb': { 'NAME': 'theotherdb', ... 'TEST_MIRROR': 'default', }, }
It still connect to the server for someotherdb
and attempts to open the non-existent database test_mydefaultdb
, which of course fails because it is supposed to be on the server for default
.
Change History (3)
comment:1 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 11 years ago
Another possibility is to have a more flexible option:
DATABASES = { 'default': { ... }, 'someotherdb': { ... 'TEST_SEPARATE_DATABASE': True, }, }
'TEST_SEPARATE_DATABASE': True
: The default (current) behavior which creates a separate test database and modifies the db connection'TEST_SEPARATE_DATABASE': None
: The behavior described in the ticket above which will remove the database from the db connections'TEST_SEPARATE_DATABASE': False
: This should leave the db connection unchanged duringsetup_databases()
, allowing for the unit tests to query the regular database. However, the Django test case classes would have to be updated to prevent the regular database from being wiped on each run. It may not be the best design for tests to depend on live data, but if the test was carefully coded, it should work well. This would alleviate the need for a separate test database server to be set up and mock fixtures to be created if only simple reads are done in the tests.
comment:3 by , 11 years ago
Type: | Uncategorized → New feature |
---|
This seems a reasonable use case to me.