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.