Testing

A check earns its place by failing when behaviour breaks and passing otherwise. Most weak tests fail at one or both.

Start from a sentence

Write the thing that must stay true in plain words: "Refunds never exceed what the customer paid." "Someone who isn't signed in can't see an order." "The menu page says Order for pickup." Then write the test that proves that sentence.

Test what the code does, not how it reads

Drive the code with inputs and assert on outputs or effects. Avoid tests that assert the source contains a string or matches a regex — they pass when the behaviour is broken and fail when you reword a comment. If you catch yourself asserting on code text, you're testing the wrong layer.

Cover the things that must never break

Spend your tests on sign-in, permissions, money, and data integrity — the places where a silent regression is expensive. A test for every getter is noise; a test that proves a non-member can't read a record is gold.

Make each run independent

A fresh, isolated environment per run. No shared mutable state between tests, no order dependence, no reliance on data a previous test left behind. Flaky tests get ignored, and ignored tests protect nothing.

Test the boundary cases

The off-by-one, the empty list, the just-expired token, the 29- vs 31-day-old order. Bugs live at edges; assert the edges explicitly.

When a check fails

Make the failure legible: a message that says what was expected and what happened. A failing test that doesn't explain itself costs more than it saves.