Why Test, and What to Test

Tests are code that checks your code. They let you change things without fear: refactor, upgrade a library or fix a bug, then run the tests and know within seconds whether anything broke. Untested code gets harder to change every month.

The testing pyramid

Many fast unit tests at the base, fewer slower tests at the top. A suite of only E2E tests is slow and flaky; a suite of only unit tests misses wiring bugs.

What to test first

Prioritise by risk: what is most costly if it breaks?

1. Money: payments, amounts, refunds, currency conversion.
2. Security: login, permissions, who can see what.
3. Data integrity: anything that writes or deletes records.
4. Core journeys: sign up, buy, learn, contact.
5. Bugs you have fixed: every bug fix gets a test so it never returns.

PandaDev's own suite follows this: tests for to_minor_units, for admin routes returning 404 to non-staff, for points being awarded only once, and for templates never showing raw translation keys.

What a good test looks like

• Tests behaviour, not implementation: "a sub-admin cannot create an admin", not "function X calls function Y".
• Independent: runs alone and in any order.
• Deterministic: same result every time; no real clock, randomness or network unless controlled.
• Readable: the name says what should happen.

Coverage

Coverage measures which lines ran during tests. It is useful for finding untested areas, but 100% coverage does not mean correct code; it only means each line ran once. Aim for high coverage of critical code and meaningful assertions everywhere.

Check yourself

• Why are there more unit tests than E2E tests?
• Which areas should be tested first?
• Why is 100% coverage not proof of correctness?