test-driven-development

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

Name the production change that should make the test fail, derive expected values by hand as literals rather than reusing code under test, and assert on real behavior instead of mock interactions. One test should cover one behavior with a clear descriptive name.

Exceptions are limited to throwaway prototypes, generated code, and configuration files, and only with explicit approval from your human partner. Exploratory coding is allowed if the exploration is discarded and the real work restarts with TDD.

Assert on real component behavior, never on the mock itself. Mock only slow or external dependencies after learning their side effects, mirror the complete real data structure, and switch to integration tests when mock setup outweighs the test logic.

A test that passes before implementation is testing existing behavior or testing nothing meaningful. It never proved it can catch the bug, so you must fix the test until it fails for the right reason — the missing feature, not a typo.