(One of my summaries of a talk at the 2016 django under the hood conference).

A quick history of django’s testing framework.

Ticket #2333 got added to django’s bug tracker before 1.0 was out: we want an integrated test framework (“Rails has it too”). A while later there was a test runner that looked at tests.py and models.py . models.py ? Yes, as at that time doctests were still very popular and models were commonly tested with doctests. The rest was for the normal tests in tests.py .

Django 1.1 added a build-in testclient for basic GET/PUT. Also TransactionTestCase was added: this one rolled back database transactions at the end of the tests. Better performance.

1.2 added a new class-based test runner. You could now also terminate the entire test run upon the first error (“failfast”).

1.3 splits the old test client into an actual client and a RequestFactory . Well, the client is a subclass of RequestFactory, something Ana doesn’t like and would like to see refactored during the sprints. Doctests turned out not to be an ideal combination of tests and documentation. Testing was harder and the documentation not clear. So doctests were discouraged.

In 1.4, more TestCases were added. SimpleTestcase for tests without databases, for instance.

1.5. Python 3 support lands in django. A full testing tutorial is added to the documentation. Several assert tests are added.

1.6. “patch” is added to the supported methods of the build-in client. Test discovery is improved. Doctest discovery was removed.

1.7 uses the new unittest. In an earlier version, the unittest2 library used to be backported, but the basic python unittest can be used now as old python versions have been deprecated: the basic unittest library includes all unittest2 functionality.

1.8. Testcase is changed again. Fixture loading is sped up.

1.9. --parallel is added: running multiple tests in parallel, if the tests support it. If you use an older django version, you might use nose’s multiprocessing plugin.