test-driven-development

Write one minimal failing test for a single behavior, run it and confirm it fails for the expected reason, then write the simplest code that passes. After the test passes, refactor while keeping all tests green, and repeat for the next behavior.

Red means writing a failing test that defines the desired behavior. Green means writing the minimal implementation to make it pass. Refactor means cleaning up duplication and names while keeping every test passing.

Exceptions are limited to throwaway prototypes, generated code, and configuration files, and only with explicit approval from your human partner. Thinking 'skip TDD just this once' is treated as rationalization, not a valid exception.

Tests should assert on real component behavior, never on the mock itself. Mock only slow or external dependencies after learning their side effects, and mirror the complete real data structure in mock responses.

Delete the implementation and start over with a failing test. Keeping it as reference or adapting it while writing tests counts as testing after, which violates the core rule that no production code exists without a failing test first.