Django Testing Gotchas

I recently started using Django's newly introduced capability to make use of test fixtures. In order to do this all test classes that need fixtures have to be subclasses of Django's custom TestCase class rather than the customary unittest.TestCase. I had written about 17 or so test cases split across two test classes. One of these test classes used Django's fixtures.

Each Django test run (kicked off by running python manage.py test) involves the following steps:

1. Create test database
2. Create the necessary tables
3. Load "initial fixtures" if any. These have to be located in a file named initial_data with suitable extension denoting fixture type (.xml, .json etc.)
4. Load fixtures specified in each test case
5. Execute any one test
6. Remove fixtures loaded in step #4
7. Repeat steps 4 through 6 until all tests have been executed.

Sounds nifty, doesn't it? That is what I thought too, until I ran into reality. All goes well until step 3. After that, the tests take an eternity to execute. OK, it took 159 seconds to execute 17 puny tests. I was surprised. My application was rather simple, involving less than a dozen tables and a few hundreds of rows. And I was only using a subset of the data to test. What was going on? I looked around and found that I was not the only one to face this problem.

After reading up more about the problem I figured that I could probably cut down on the time taken by "refactoring" my tests and moving unnecessary fixtures out to "initial fixtures" so that they would only be loaded once. Luckily this would work in my case as my app only used the data for reference; it did not modify any. I was therefore not constrained to load the data before each test.

I made the necessary changes and re-ran my test cases. The time taken to execute the test cases improved ever so slightly. It now took about ~140 seconds.

I was still unhappy with the results. Since I was not using any fixtures, I decided to substitute Django's TestCase with unittest.TestCase. And voilà! It was as I had engaged hyper drive. 24 tests now took a mere 0.2 seconds to run!

Naturally the question that came to my mind was that in the absence of fixtures, what on earth was taking up so much time? Django is known for its speed vis a vis Rails; I had come to expect the same kind of superior performance while running tests too. I don't have an answer right now. I hope to come up with one after I take a look at Django's innards.

Moving from Rails to Django: Replacing flash[:notice]

One of the most common practices I came across while learning Rails is the flash[:notice] mechanism used to send (error) messages to the template. Consequently it was also one of my first targets to migrate when I started moving a pet application from Rails to Django.

I came up with a simple (and all too obvious) way to send error messages to the template. I am sure that there are better ways to do this. If you know of any, please take a minute to share them.

First, the Rails snippet. def index ... begin army = Army.find(params[:army][:id]) rescue StandardError => se flash[:notice] = "Vare, legiones redde!" return end ... end Next, the equivalent in Django. from django.shortcuts import render_to_response def index(request): ... try: army = Army.objects.get(id = request.POST["army"]) except ( KeyError, Army.DoesNotExist ): return render_to_response( "some_template.html", { "flash" : "Vare, legiones redde!" } ) ... The template in Rails ... ... <% if @flash[:notice] -%> <div id="flash"> <div><%= @flash[:notice] %></div> </div> <% end -%> ... ... and the template in Django. ... {% if flash %} <div id="flash"> <div>{{ flash }}</div> </div> {% endif %} ... While testing in Django, flash can be treated just like any other context variable.

Moving from Rails to Django: Migrating Tests

Context
I am in the process of migrating one of my small "pet" applications developed in Ruby on Rails to Python using Django. One of my first concerns was migrating tests, both unit (testing models) and functional (testing 'controllers' in Rails/'views' in Django) from one framework to the other. After looking around the documentation, asking questions and conducting some experiments I have some answers. Here is a listing of what I have found out so far.

Note
These examples will only work with the latest development version of Django.

Locating your tests
Rails
Usually located under the path [path_to_app]/test/functional/. There is usually one test source per controller, named as [controller_source_without_extension]_test.rb. For example if the source for a controller, say, 'Generator' is written in [path_to_app]/app/controllers/generator_controller.rb, then the corresponding test should be present in a file named generator_controller_test.rb

Django
The easiest way (see the official documentation) is to add all your tests to a file called tests.py and drop it in the application folder, at the same level as your models.py and views.py.

However I prefer to have a separate test source structure if I can help it. This has the added advantage of keeping I decided to adopt the convention used by Rails and came up with the following tree:

• [project]/[application]/test/functional/ for functional tests and
• [project]/[application]/test/unit/ for model tests.

Don't forget to add the __init__.py files to the tree as applicable to make these accessible as python modules. You will still need to retain the tests.py except that you will have to add a line to import your test case classes and nothing else. Test runner will automatically pick up the test classes and run them. # GeneratorTests is a subclass of unittest.TestCase from django_iwg.btd.test.functional.generator_tests import GeneratorTests
Fixtures
Fixtures are readily available in Rails. There are not quite there yet in Django and I am as righteously angry as the next ex-Rails user ;) But do not worry, they are on their way and will be available shortly. I am experimenting with a really dirty solution in the meantime. More on this in a subsequent post.

Writing Tests - setup
Rails
A typical setup() method in Rails looks like this: require File.dirname(__FILE__) + '/../test_helper' require 'generator_controller' class GeneratorControllerTest < Test::Unit::TestCase def setup @controller = GeneratorController.new @request = ActionController::TestRequest.new @response = ActionController::TestResponse.new end end Django
The framework provides a test client to simulate browser calls. The best place to create a test client object would be the setup method. import unittest from django.test.client import Client class GeneratorTests(unittest.TestCase): def setUp(self): self.client = Client()
Writing Tests - GET requests
Rails
My first objective was to test if a GET request to the controller/URL 'generator/index' was being handled properly. "Properly" in this case means three things:

• Ensure that the response came back with an HTTP status of 200 OK;
• Ensure that the appropriate template was used; and
• Ensure that instance variables were present and had expected values.

The resulting test looked like this: def test_GET_index_returns_200_OK get :index assert_template "generator/index" assert_response :success assert_equal assigns(:campaigns).length, 14 end
Django
While the objectives remain the same, the steps vary. The key differences I noticed were:

• There are no built-in wrapper methods for GET/POST. It should be noted that it is easy to enough to code wrappers should one so wish.
• Likewise there are no equivalents for wrappers such as "assert_template" or "assert_response"
• Django uses a different philosophy when it comes to passing variables to templates. Instance variables are not directly passed to templates; rather they have to be explicitly passed using a context object or a call to locals()

The resultant code looks like this: def test_GET_index_returns_200_OK(self): response = self.client.get("/generator/index/") self.failUnlessEqual(response.status_code, 200) self.failUnlessEqual(response.template.name, "generator/index.html") self.failUnlessEqual(len(response.context["campaigns"]), 14)
Writing Tests - POST requests
Rails
A simple "happy path" POST request test looks like this in Rails: def test_POST_index_saves_army_in_session_and_redirects post :index, :army => {:id => 1} assert_equal 1, get_session_variable(:army).id assert_redirected_to(:action => "number_of_units") end Here, in addition to checking the response I am also verifying that a particular session variable was set properly.

Django
Here again we find that there are no wrappers for session and that it is easy enough to add some. The session object itself is readily available and can be accessed using the test client. def test_POST_index_saves_army_in_session_and_redirects(self): response = self.client.post("/generator/index", {"army" : 1}) self.failUnlessEqual(response.status_code, 302) self.failUnlessEqual(response.headers["Location"], "/generator/number_of_units/" ) self.assertEqual(self.client.session["army"].id, 1)
Running Tests
Rails
The easiest way is to execute ./rake from the command line. There are separate tasks available (such as test:functional, for instance) in case you wish to run the functional tests only.

Django
The easiest way is to execute ./manage.py test from the command line. This will run the tests for all applications in the project. If you wish to test only one application, feed its name as an additional parameter.

Django Template Nuances
Django provides simple inheritance mechanism for templates. I personally like it :) What should be remembered is that using inheritance changes the testing process slightly. For instance, consider a view index that renders a template say, index.html. This template inherits from another, named base.html. A GET request test for the view would look like this: def test_GET_index_returns_200_OK(self): response = self.client.get("/generator/index/") ... template_index = [template.name for template in response.template].index("generator/index.html") self.failUnlessEqual(len(response.context[template_index]["campaigns"]), 14) Note the difference from the earlier test. When template inheritance comes into play, response.template will resolve into a list of all the templates involved in the hierarchy, listed parent first. Corresponding to each template, there will be a separate context object at available at the same index in response.context (which will also resolve into a list)