test-driven-development

Follow the red-green-refactor cycle: write one minimal failing test, run it to confirm it fails for the expected reason, write the simplest code to pass it, verify all tests pass, then refactor while keeping tests green. Repeat for each new behavior.

Tests written after code pass immediately, which proves nothing about whether they test the right behavior. Watching a test fail first confirms it actually exercises the missing feature and catches real bugs rather than mirroring the implementation.

Only for throwaway prototypes, generated code, or configuration files, and only with explicit approval from your human partner. Exploration is fine, but the exploratory code should be discarded and rewritten test-first.

Asserting on mock elements verifies the mock exists, not that the component works. Tests should exercise real behavior; if isolation requires mocks, assert on the component's observable behavior rather than mock internals.

A hard-to-write test signals an unclear or overly coupled design. Simplify the interface, use dependency injection instead of heavy mocking, and extract test helpers rather than adding test-only methods to production classes.