Starting my first big Django-project (Building.ua), I hadn’t know anything about TDD except the fact it is. Project was done but it is very buggy and hard for future develop.
After very productive work with Andrey Khavryuchenko , I’ve learnt his model of tests and now try to add some points to it to make it cover near 100% of the Django application.

All tests in Django-TDD I’d like to divide into parts:
— Unit tests
— Integration and modification tests
— Twill html tests
— Selenium tests
— Other specific tests (e.g. test RTF or PDF output)

Andrey use nosetest in all python projects. And this model is better for me as standard Djando UnitTest derived testrunner. The biggest issue of such model is that you can use one test templates for all your python projects. Second, we use nosetest with coverage plugin which give us very useful metric to know how code is tested.

Unit tests for every new Django model looks like:
— create/edit/delete object of the model
— call unicode() and get_absolute_url() methods

Extensions of the model results appearing new tests in the testscase for this model.

All unit and integration django tests we create as the subclasses of the DbMock class. As a result every test has it’s own clean database and we don’t care about it.

For testing simple html functions and interactions we use Twill. Twill give the possibility to run by the pages, find and fill the forms and check results. Of course, you could use Selenium for this too, but in this case Twill is more cheaper solution.

To run Twill (and Selenium), we create virtual Django WSGI server and connect to it from the tests.


For testing javascript iterations, we use Selenium-RC, which have good python interface. The biggest problem for Selenium tests — is to run this tests on the buildbot servers. The one solution I see — is to setup server with X and set Selenium to run Firefox on this server.

I am planning to write some code in next articles to show our examples for running nose/twill/selenium tests for Django application.