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 test and the full suite, then refactor while keeping tests green.

RED means writing a failing test that defines desired behavior. GREEN means writing the minimal code to make it pass, even hardcoding. REFACTOR means cleaning up duplication and names while keeping all tests passing.

No. Writing all tests first is horizontal slicing and produces brittle tests designed before the implementation teaches you the real interface. Use vertical tracer bullets: one RED-GREEN cycle per behavior, repeated.

Only for throwaway prototypes, generated code, or configuration files, and only after asking the user first. Exploration is fine, but the exploratory code should be discarded and the real implementation restarted test-first.

A test that passes immediately proves nothing; it may test existing behavior or the wrong thing. Watching it fail confirms the test actually exercises the missing feature and fails for the expected reason, not a typo.

Delete the code and start over with TDD. Keeping it as reference or adapting it while writing tests is effectively testing after, which biases tests toward the implementation rather than the required behavior.