tdd
TDD
Work in vertical slices: one test → one minimal implementation → refactor while green → repeat.
Before RED
Inspect existing tests, public interfaces, and project conventions. Choose the narrowest trustworthy seam yourself; do not ask the user to approve the test layer. A seam is the public boundary where behavior can be driven and observed, such as a function, API, CLI, UI interaction, or service interface.
If no fast, reliable test can exercise the behavior through a stable seam, use the nearest trustworthy validation instead and say that the work was not TDD.
The loop
- RED — Write one test for the next observable behavior. Run it and confirm it fails for the predicted reason, not a typo, missing import, or unrelated path.
- GREEN — Write only enough production code to pass that test. Run it, then run the nearest related tests.
- REFACTOR — Improve names, structure, and duplication without changing behavior. Keep tests green throughout.
Then choose the next behavior and repeat. Do not write a batch of tests followed by a batch of implementation.
Bug fixes require a failing regression test that reproduces the original symptom before the fix.