Python & Django
Confidence to Change Things
Last updated:
Test what would be expensive to get wrong
- Calculations — pricing, tax, anything with arithmetic
- Permissions — who can see and do what, including cross-user access
- Business rules — the conditions that govern the workflow
- Integrations — including what happens when they fail
- Anything that has broken before
Permission tests are the ones most often missing and the ones with the most serious consequences. Test that user A cannot reach user B's records, explicitly.
Different tests for different jobs
| Type | Covers |
|---|---|
| Model tests | Business rules and validation |
| View tests | Complete request-response journeys |
| Permission tests | Who can access what |
| Form tests | Validation, including failure cases |
| Task tests | Background work, run synchronously |
Use realistic data
- Factories that produce plausible records, not minimal ones
- The awkward cases that broke it before
- Empty and boundary conditions
- Volumes large enough to catch query problems
Assert query counts
A test that asserts a page issues no more than a set number of queries catches performance regressions before they reach production.
It is one of the highest-value test types in a Django application and it is rarely written.
Run them automatically
On every push, blocking a merge on failure. Tests that require someone to remember to run them stop being run within a month.
That is a day of setup and it is what turns a test suite into a safety net rather than an intention.
Frequently asked questions
How much coverage is enough?
Enough to change the code confidently. Usually the business rules, permissions and calculations rather than every line.
Should tests use a real database?
Yes — Django's test runner creates one. Mocking the database tests your mocks rather than your queries.
Are view tests worth it?
Very. A small number covering the main journeys catches more real problems than a large number of unit tests.
How do we test legacy Django code?
Characterisation tests at the view level first, then narrow down as you refactor.
Afraid to change your own application?
Start with permissions and calculations. Those are where the expensive mistakes are.
Related services
What we build for problems like this one