10 tips on testing Django projects

Write Tests

It is surprising how many developers still have no idea how to write tests for their projects. Some of the reasons stopping them, to name a few, are:

• “code does not exist if it’s not tested” mantra taken way too seriously;
• seeming lack of time;
• involvment of management;
• lack of courage.

Despite all advantages testing can give, they do not test at all.

Write Tests for Existing Code

Let’s assume code is deployed and works fine, it just lacks tests. Write tests when you’ll modify that code, so you’ll check that modifications work. All-at-once approach does not work here.

Run Your Tests

This may seem funny, but some developers do not run tests for project. They write tests, but never run them :) Thus project has large amount of tests that practically test nothing.

Do Not Test Everything

Tests don’t guarantee that you’ll have no errors. Common mistake developers new to testing do may be called ’test everything’. You can’t test everything, unless you want to write tests for your tests. Test important things.

Use Framework

Use test framework that will make you productive: unittest, nose, pytest, etc. There are integration packages for Django and these frameworks, for example, pytest-django and django-nose. Django has built-in support for unittest.

Learn Your Tools

Whether it’s pytest, unittest, nose or something else, you need to know what it is capable of. For instance, pytest has built-in facilities for monkey patching, temporary dir creation, and test parametrization. On the other hand, nose has profiler plugin.

Use Right Tool for Job

I noticed that sometimes developers tend to use most powerful tool even if simplest one will do great. For instance, they use Selenium to check simple HTML form, while Django’s built-in django.test.client.Client, and django-webtest exist.

Mock If It’s Worth It

Mocking is not a panacea. Sometimes it’s better to have small functional test instead of large unit test. It’s good to avoid too much code, especially if it does the same thing: checks that some piece of your project works as expected. Besides, who will check that mock object really looks like object you mock?

Move Tests Outside of Regular Code Directory

I started to use non-django-admin.py approach, and generally I like it. manage.py test appnames is worse for my project because it requires me to explicitly state what apps it should look for tests in. Separate directory for tests allows me to structure tests any way I want: say, I can store unit tests and functional tests in separate directories in one case, and store them together in other case (for example). So, to conclude, custom Django test runner is not something special, and if you feel you need it, write it—it will save you some time later.

Do Not Duplicate Efforts

Once I wanted to test form that accepts payment data from payment system in one of projects I support. Easiest way to do that was to test form (it was usual Django form with bunch of fields and validation). But I quickly realized that later I’ll want to test view related to that form, and tests will definitely look same. That’s why I decided to write functional tests for view instead of tests for both form and view. That saved me time and money, because I found few bugs and checked that view and form nicely operate and interoperate.