Opened 10 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 Marc Tamlyn, 10 years ago

Triage Stage: UnreviewedAccepted

This seems a reasonable use case to me.

comment:2 by yscumc, 10 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 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.

comment:3 by Carl Meyer, 10 years ago

Type: UncategorizedNew feature
Note: See TracTickets for help on using tickets.
Back to Top