test-driven-developmentlisted

# Test-Driven Development (TDD) ## Overview Write the test first. Watch it fail. Write minimal code to pass. **Core principle:** if you didn't watch the test fail, you don't know whether it tests the right thing. Follow the letter of these rules and you'll get the spirit of them for free. ## When to Use Any change with behavior to assert: new features, bug fixes, refactoring, behavior changes. The exceptions are observable, so apply them yourself without stopping to ask: throwaway prototypes (code you will delete, not ship), generated code, and configuration files with no behavior to assert. Outside those, the thought "I'll skip TDD just this once" is a signal to slow down, not a reason to skip. ## The Core Rule Production code follows a failing test. Write the test, watch it fail, then write the code. If you wrote implementation code before the test, delete it and start fresh from the test. Don't keep it as reference and don't adapt it while writing tests; code you keep around will shape the test toward what you already built, which is the thing TDD is meant to prevent. The hours already spent are spent either way; the real choice is between a rewrite you can trust and code you can't. Reimplement from the test. ## Red-Green-Refactor 1. Red: write one minimal failing test that shows what should happen. One behavior per test, a name that describes that behavior, real code rather than mocks wherever possible. A test that exercises a mock proves only the mock. 2. Veri