test-driven-development

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.

Where the test goes: seams

A seam is the public boundary you test at — the interface where behaviour is observable without reaching inside. Tests live at seams, never against internals: code behind the seam can be rewritten entirely and the tests shouldn't care. The tell that you've tested inside the seam is a test that breaks on a refactor even though behaviour didn't change.

You can't test everything, so decide the seams before writing any test: name the public interface under test and, when the choice isn't obvious, confirm it with the user ("what's the public interface here, and which paths matter most?"). Agreed seams put the testing effort on critical paths and complex logic instead of spraying assertions over every private helper.

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.