Testing Django – part 4 – setting up a dedicated CouchDB for tests

In this part of the Testing Django series we will learn how to set up a dedicated CouchDB database for our automated Django tests. It builds on the previous parts that can be found here:

Django supports different SQL systems natively. If you want to use NoSQL solutions for making your data persistent you need to tinker a little bit yourself sometimes. I used CouchDB and Couchdbkit in a Django project. One problem was that the test data was saved in the same CouchDB database as data that was entered through the “productive” web interface. Here I describe how to have separate a database for each case.

So let us get into the described trouble by changing our model to be made persistent as CouchDB document.

First we install Couchdbkit:

$ sudo easy_install -U Couchdbkit

Then we have to modify the settings.py so that our Django project is aware of it:

    'couchdbkit.ext.django', # Add this
    'fruitsalad.fruits', # Added in previous parts
    'django_nose', # Added in previous parts
    'lettuce.django', # Added in previous parts

And we have to specify (also in settings.py) a database to use. The database does not have to exist as Couchdbkit will take care of this.

     ('fruitsalad.fruits', '')

Then we adapt our model:

from couchdbkit.ext.django.schema import *

class Fruit(Document):
    name = StringProperty()
    color = StringProperty()

    def set_name(self, name):
        self.name = name

    def set_color(self, color):
        self.color = color

    def is_yummy(self):

    def become_brown(self):
        self.color = "brown"

    def disappear(self):
        self.color = "transparent"

Okay, let’s use Django‘s shell to create such a fruit object and save it to the CouchDB database.

$ ./manage.py shell
Python 2.6.5  
Type "copyright", "credits" or "license" for more information.

IPython 0.10 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from fruitsalad.fruits.models import Fruit

In [2]: f = Fruit()

In [3]: f.name = "Banana"

In [4]: f.color = "yellow"

In [5]: f.save()

We can check the existence by using curl:

$ curl -X GET

This means we have (as expected) one document in the database. To have a closer look at it:

$ curl -X GET

Alternatively use CouchDB‘s dashboard Futon that might be accessible at

depending on your CouchDB configuration.

We have to adapt our model test a little bit for the new constellation:

class TestFruit(object):

    def setup(self):
        self.fruit = Fruit()

    def test_color(self):
        nt.assert_equal(self.fruit.name, "Papaya")
        nt.assert_equal(self.fruit.color, "orange")

    def test_yumminess(self):

    def test_color_change(self):
        nt.assert_not_equal(self.fruit.color, "orange")
        nt.assert_equal(self.fruit.color, "brown")

    def teardown(self):

If we run the test now …

$ ./manage.py test
Creating test database 'default'...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
sync `fruitsalad.fruits` in CouchDB
Installing index for auth.Permission model
Installing index for auth.Group_permissions model
Installing index for auth.User_user_permissions model
Installing index for auth.User_groups model
Installing index for auth.Message model
No fixtures found.
nosetests --verbosity 1
Ran 6 tests in 0.352s

Destroying test database 'default'...

… we can see that the documents produced by it are tainting the “productive” database:

$ curl -X GET

With every run it will become more documents. But we can circumvent this problem easily. We simply modify settings.py so that the application uses a different database if it is invoked by the test runner.

if "test" in sys.argv:
	('fruitsalad.fruits', ''),

If we run the tests againg …

$ ./manage.py test

we see that the database fruits_test is filled instead of the fruits database.

$ curl -X GET

The only downer is that our test database is getting bigger and bigger. So we have to clean it. To that we modify
fruits/tests.py slightly. In the top of the file we add

import fruitsalad.settings as settings
from couchdbkit.client import Database

and then we chance the setup method of the testing class :

    def setup(self):
        # cleaning the database
        db_url = settings.COUCHDB_DATABASES[0][1]  
        database = Database(db_url)
        # nothing new
        self.fruit = Fruit()

Now before every test run the previous database content is removed. Alternatively move this cleaning part into the teardown method. The advantage of the here presented solution is that you can have a look a the data in the database if you need to.