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. Run the full test suite afterward to check for regressions before refactoring.

Red means writing a failing test, green means writing minimal code to make it pass, and refactor means cleaning up duplication and names while keeping tests green. Each cycle covers exactly one behavior before moving to the next.

No, that is horizontal slicing and produces brittle tests designed before the implementation teaches you the real interface. Use vertical tracer bullets instead: alternate one test with one implementation slice end to end.

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 work restarted test-first.

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 fails for the expected reason, not a typo.

Delete it and start over with TDD. Keeping it as reference or adapting it while writing tests biases the tests toward the implementation, which defeats the purpose of test-first development.