test-driven-development

Write one minimal failing test for a single behavior, run it with pytest to confirm it fails for the expected reason, then write the simplest code to make it pass. After green, refactor while keeping all tests passing, and repeat one cycle at a time.

Red means writing a failing test that defines the desired behavior. Green means writing the minimal code to make that test pass, even with hardcoded values. Refactor means cleaning up duplication and names while keeping every test green.

Write tests before code. Tests written after implementation pass immediately, which proves nothing—they may test the wrong thing or mirror the implementation rather than the required behavior. Watching a test fail first proves it actually tests something.

Only for throwaway prototypes, generated code, or configuration files, and only after asking the user first. Exploration is allowed, but the exploratory code must be discarded and the real implementation restarted with a failing test.

An immediately passing test means you are testing existing behavior, not new functionality. Fix the test so it targets the missing feature, run it again, and confirm it fails for the expected reason before writing any implementation code.

Avoid testing mock behavior instead of real code, testing implementation details rather than behavior, covering only the happy path, and writing all tests upfront in a horizontal slice. Use vertical tracer bullets: one test and its implementation per cycle.