Write Tests

A good test fails only when real behavior breaks, and passes through every refactor or config change that preserves it. Most bad tests fail the opposite way: red on harmless changes, green while the real path is broken. Every rule below serves that one goal.

Default to end-to-end or system-level tests for regression coverage; use a unit test only for specific, complex business logic when fast feedback will materially speed development.

For deciding whether coverage adds independent proof, where it belongs, or which existing tests can go, use audit-tests.

Workflow: tracer bullets, not a batch

1. Write ONE test at a time. Assert first, watch it go red on the un-fixed code, make the code earn green, learn, then write the next. Never a batch up front: a batch written against imagined behavior pins what you guessed, those tests pass when the mechanism breaks and fail when it's fine. Each green cycle tells you what the next test should actually assert.
2. Iterate on the fastest focused runner (one file, one test name), and run the full suite only as a final gate before handing off. Check the exit code, not just the output, a runner that prints nothing and a green run look the same. On failures, read EVERY red test before fixing one; they often share a root cause.
3. Before calling it done, prove the test can fail (below) and walk the review checklist.

What to assert