test-driven-developmentlisted

Write the test before the code, watch it fail, then write only enough code to make it pass. The point of seeing it fail first is simple: a test you never watched fail might be testing nothing. Tests written after the fact pass immediately, and a test that has only ever passed proves nothing about whether it would catch the bug. ## The one rule **No production code without a failing test that demands it.** If you wrote the implementation first, the honest move is to delete it and start from the test — not keep it "as reference" and reconstruct it, which is just testing-after wearing a costume. Implement fresh from what the test asks for. Exceptions worth asking the user about: throwaway prototypes, generated code, pure config. Everything else — features, bugfixes, behaviour changes — goes test-first. The thought "I'll skip TDD just this once" is the rationalisation this skill exists to catch. ## The cycle: red → green → refactor ### Red — write one failing test Write a single test for one behaviour, with a name that describes that behaviour. Exercise the real code, not a mock of it — a test that asserts a mock was called tests the mock, not your logic. Mock only what you genuinely can't run (network, clock, filesystem) and only when unavoidable. Good: `test('retries a failed operation three times before giving up')` — clear name, one behaviour, real code path. Avoid: `test('retry works')` driving a pre-scripted mock — vague, and it verifies the mock's script rather than