How to run django unit-tests on production database?
In case someone googles here searching for the solution for a given problem, here is the skeleton on how to perform unit tests on django production database. Check the django docs section here, for the file/directory structure, and instructions on where to put the given code. It should go in yourapp/management/commands/newcommandname.py
, and both the management and commands folders should contain empty __init__.py
files which makes python treat them as valid modules.
The test suite can by run as:
$python manage.py newcommandname
And here comes the code you should put in yourapp/management/commands/newcommandname.py
:
from django.core.management.base import BaseCommand
import unittest
class Command(BaseCommand):
help = """
If you need Arguments, please check other modules in
django/core/management/commands.
"""
def handle(self, **options):
suite = unittest.TestLoader().loadTestsFromTestCase(TestChronology)
unittest.TextTestRunner().run(suite)
class TestChronology(unittest.TestCase):
def setUp(self):
print "Write your pre-test prerequisites here"
def test_equality(self):
"""
Tests that 1 + 1 always equals 2.
"""
from core.models import Yourmodel
self.failUnlessEqual(1 + 1, 2)
First, if you're running it on the production database, it isn't much of a "unit" test.
It's a first-class batch job and needs to be treated like a first-class production batch job.
You cam't to use the Django test
command for looking at production data. It always creates an empty database which is populated from fixtures in the TestCase.
You could make your production database processing a proper management command. This has the environment all properly configured so that your command can simply use the Django ORM to process your data.
The alternative is to be sure that you configure your settings. Either
use the DJANGO_SETTINGS_MODULE
environment variable or use the settings.configure()
function to create an environment.
You can then import the models and do the processing you want to do against the production database.
You can call it "test" if you want to, but you're looking at production data, so it's got to be treated like production application with respect to getting the settings file and using the proper ORM configuration.