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 pass. Re-run the specific test and the full suite with pytest tests/ -q before refactoring.

RED means writing a failing test that defines desired behavior, GREEN means writing minimal code to make it pass, and REFACTOR means cleaning up duplication and names while keeping all tests green. Each cycle covers one behavior at a time.

No. Writing all tests first is horizontal slicing and produces brittle tests detached from the real interface. Use vertical tracer bullets instead: complete one RED-GREEN cycle per behavior so each test builds on what the implementation taught you.

Only for throwaway prototypes, generated code, or configuration files, and only after asking the user explicitly. Exploratory spikes are allowed, but the exploration code must be discarded and the real implementation restarted with TDD.

A test that passes immediately proves nothing—it may test the wrong thing or existing behavior. Watching it fail confirms the test actually exercises the missing feature and would catch the bug it targets.

Write a failing test that reproduces the bug first, then implement the minimal fix until the test passes. This proves the fix works and creates a permanent regression test, pairing naturally with systematic debugging.