test-driven-development

Use when implementing any feature or bugfix, before writing implementation code

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 if it tests the right thing. Violating the letter of the rules is violating the spirit of the rules. When to Use Always: - New features - Bug fixes - Refactoring - Behavior changes Exceptions (ask your human partner): - Throwaway prototypes - Generated code - Configuration files Thinking "skip TDD just this once"? Stop. That's rationalization. The Iron Law NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST Write code before the test? Delete it. Start over. No exceptions: - Don't keep it as "reference" - Don't "adapt" it while writing tests - Don't look at it - Delete means delete Implement fresh from tests. Period. Red-Green-Refactor dot digraph tddcycle { rankdir=LR; red [label="RED\nWrite failing test", shape=box, style=f…