test-driven-development

Write one minimal failing test describing the desired behavior, run it and confirm it fails for the expected reason, then write the simplest code that makes it pass. After green, refactor while keeping tests passing, and repeat for the next behavior.

Name the production change that would make the test fail, derive expected values by hand rather than from the code under test, and assert real behavior instead of mock interactions. Keep each test focused on 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. Exploration is allowed, but the exploratory code must be discarded and rewritten test-first.

An immediately passing test means it is testing existing behavior or is tautological, so it proves nothing. Fix the test to target the missing feature, then watch it fail before writing any implementation code.

Mock only slow or external dependencies after learning the real method's side effects, and mirror the complete real data structure. Never assert on the mock itself; if mock setup outgrows the test logic, switch to an integration test with real components.