tdd-workflow

Begin with the simplest non-trivial case, such as the happy path with one input, and write the smallest failing test expressing that behavior. Then write minimal code to pass, refactor while green, and commit at each green step.

Red means writing the smallest failing test for the next behavior, green means writing the least code to make it pass, and refactor means improving the design while tests stay green. Each cycle covers exactly one behavior.

Use a test double only when the real collaborator is slow, non-deterministic, or does not exist yet. Never mock types you do not control; wrap them in a thin abstraction first, since a test that mocks everything tests nothing.

Difficulty writing tests usually signals design problems: hard-to-construct objects indicate too many collaborators, and needing to mock everything reveals hidden coupling. Introduce abstractions and apply single-responsibility principle to fix the design.

Avoid writing code before tests, skipping the refactor phase, tests duplicating implementation details, large shared test fixtures, and asserting on private methods or exact SQL strings. These produce brittle change-detector tests rather than behavior verification.