How do I run a unit test against the production database?

Question

How do I run a unit test against the production database instead of the test database?

I have a bug that's seems to occur on my production server but not on my development computer.

I don't care if the database gets trashed.

Answer 1

Is it feasible to make a copy the database, or part of the database that causes the problem? If you keep a backup server, you might be able to copy the data from there instead (make sure you have another backup, in case you messed the backup database).

Basically, you don't want to mess with live data and you don't want to be left with no backup in case you mess something up (and you will!).

Answer 2

Use manage.py dumpdata > mydata.json to get a copy of the data from your database.

Go to your local machine, copy mydata.json to a subdirectory of your app called fixtures e.g. myapp/fixtures/mydata.json and do:

manage.py syncdb # Set up an empty database
manage.py loaddata mydata.json

Your local database will be populated with data and you can test away.

Answer 3

If you database supports template databases, use the production database as a template database. Ensure that you Django database user has sufficient permissions.

If you are using PostgreSQL, you can easily do this specifying the name of your production database as POSTGIS_TEMPLATE(and use the PostGIS backend).

Answer 4

Make a copy the database... It's really a good practices!!

Just execute the test, instead call commit, call rollback at the end of.

Answer 5

The first thing to try should be manually executing the test code on the shell, on the production server.

python manage.py shell

If that doesn't work, you may need to dump the production data, copy it locally and use it as a fixture for the testcase you are using.

If there is a way to ask django to use the standard database without creating a new one, I think rather than creating a fixture, you can do a sqldump which will generally be a much smaller file.

Answer 6

Short answer: you don't.

Long answer: you don't, you make a copy of the production database and run it there

Answer 7

If you really don't care about trashing the db, then Marco's answer of rolling back the transaction is my preferred choice as well. You could also try NdbUnit but I personally don't think the extra baggage it brings is worth the gains.

How do you test the test db now? By test db do you mean SQLite?

HTH,
Berryl

Answer 8

I have both a full-on-slow-django-test-db suite and a crazy-fast-runs-against-production test suite built from a common test module. I use the production suite for sanity checking my changes during development and as a commit validation step on my development machine. The django suite module looks like this:

import django.test
import my_test_module
...
class MyTests(django.test.TestCase):
    def test_XXX(self):
        my_test_module.XXX(self)

The production test suite module uses bare unittest and looks like this:

import unittest
import my_test_module
class MyTests(unittest.TestCase):
    def test_XXX(self):
        my_test_module.XXX(self)
suite = unittest.TestLoader().loadTestsFromTestCase(MyTests)
unittest.TextTestRunner(verbosity=2).run(suite)

The test module looks like this:

def XXX(testcase):
    testcase.assertEquals('foo', 'bar')

I run the bare unittest version like this, so my tests in either case have the django ORM available to them:

% python manage.py shell < run_unit_tests

where run_unit_tests consists of:

import path.to.production_module

The production module needs a slightly different setUp() and tearDown() from the django version, and you can put any required table cleaning in there. I also use the django test client in the common test module by mimicking the test client class:

class FakeDict(dict):
    """
    class that wraps dict and provides a getlist member
    used by the django view request unpacking code, used when
    passing in a FakeRequest (see below), only needed for those
    api entrypoints that have list parameters
    """
    def getlist(self, name):
        return [x for x in self.get(name)]

class FakeRequest(object):
    """
    an object mimicing the django request object passed in to views
    so we can test the api entrypoints from the developer unit test
    framework
    """
    user = get_test_user()
    GET={}
    POST={}

Here's an example of a test module function that tests via the client:

def XXX(testcase):
    if getattr(testcase, 'client', None) is None:
        req_dict = FakeDict()
    else:
        req_dict = {}
    req_dict['param'] = 'value'
    if getattr(testcase, 'client', None) is None:
        fake_req = FakeRequest()
        fake_req.POST = req_dict
        resp = view_function_to_test(fake_req)
    else:
        resp = testcase.client.post('/path/to/function_to_test/', req_dict)
    ...

I've found this structure works really well, and the super-speedy production version of the suite is a major time-saver.