[Django] #21742: Unable to prevent creation of a database during test runs
Django
-----------------------------------+--------------------
Reporter: yscumc | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------
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`.
--
Ticket URL: <https://code.djangoproject.com/ticket/21742>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: yscumc | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by mjtamlyn):
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
This seems a reasonable use case to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/21742#comment:1>
Django
Reporter: yscumc | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by yscumc):
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 during `setup_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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21742#comment:2>
Django
Reporter: yscumc | Owner: nobody
Type: New feature | Status: new
Component: Testing framework | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by carljm):
* type: Uncategorized => New feature
--
Ticket URL: <https://code.djangoproject.com/ticket/21742#comment:3>
Django
Reporter: yscumc | Owner: marcov
Type: New feature | Status: assigned
Component: Testing framework | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by marcov):
* owner: nobody => marcov
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/21742#comment:4>
Django
Reporter: yscumc | Owner:
Type: New feature | Status: new
Component: Testing framework | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by marcov):
* status: assigned => new
* owner: marcov =>
--
Ticket URL: <https://code.djangoproject.com/ticket/21742#comment:5>
Django
Reporter: yscumc | Owner: sgzsh269
Type: New feature | Status: assigned
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by sgzsh269):
* owner: => sgzsh269
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/21742#comment:6>
Django
Reporter: yscumc | Owner:
Type: New feature | Status: new
Component: Testing framework | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by sgzsh269):
* owner: sgzsh269 =>
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/21742#comment:7>