TDD
Make the behaviour executable before making it work. The point is not ceremony:
a test written first describes what the caller needs, while a test written after
describes what the code happens to do.
Write the test in the style the project already uses. Where the project ships a
test skill for the language, that skill wins. Failing that, read two neighbouring
test files and follow them. Failing both, the shape is: named as a sentence, built
from setup, mock, test and verify blocks separated by blank lines, and carrying no
comments.
That shape is also the fastest way to write step 2. Name the behaviour, write the
verify block first, then work backwards to the setup that makes it reachable.
The loop
- Name the behaviour. One sentence, in the caller's terms. That sentence is
the test name, and if it will not come out as a sentence the behaviour is not
understood well enough to write yet.
- Write the smallest failing test. It asserts the behaviour, never the
implementation you are about to write.
- Run it, and read the failure. It must fail for the reason you expect. A
test that passes immediately is testing something else. A test that fails on a
missing import is not evidence yet.
- Write the smallest code that passes. Not the general case, not the version
with the options object nobody asked for.
- Run it again. Green.
- Clean up while green. Both sides: the code, and the test that is now
longer than it needs to be.
- Repeat for the next behaviour, not the next line.
For a bug, the same loop with step 1 fixed for you: the test is the reproduction,
and it must fail before the fix and pass after it.
What the first test asserts
The behaviour a caller would notice. Not the shape of an intermediate value, not
the number of times a collaborator was called, not a snapshot of a structure.
Start at the boundary that is cheap to call. The unit is whatever has a real
seam, which is often a function two layers in rather than the exported one.
When to skip
Do not force a test. Skip the loop when the only available test would need broad
harness setup, brittle mocks, slow end-to-end infrastructure, production-only
state, or a fixture churn larger than the change.
Skipping is a decision you say out loud, not one you make silently. Name why the
test path is not worth it and what you did instead: a script, a manual
reproduction, a screenshot from the real app, a log assertion.
Prefer no test to a bad test. A bad test is one that mostly exercises mocks,
encodes the implementation, depends on timing or global state, or would be
deleted the moment it had proved the fix.
Guardrails
- Never change an existing test to match a wrong implementation.
- Never weaken an assertion to get to green. Either the behaviour changed, and
the test name changes with it, or there is a bug.
- Keep a regression test focused on its bug. Unrelated coverage is a separate
change.
- A flaky bug still gets a deterministic test. Pin the signal, not the timing.
- If the bug is one of a class, land the focused test first and consider the
siblings after.
Report the evidence
Not "added a test". Name the test, the failure it produced before the fix, and
the run that passed after. If failing-first could not be shown, say why, and name
the check used instead.