test-driven-development

# 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 the user first):** - 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 Cycle ### RED — Write Failing Test Write one minimal test showing what should happen. **Good test:** ```python def test_retries_failed_operations_3_times(): attempts = 0 def operation(): nonlocal attempts attempts += 1 if attempts < 3: raise Exception('fail') return 'success' result = retry_operation(operation) assert result == 'success' assert attempts == 3 ``` Clear name, tests real behavior, one thing. **Bad test:** ```python def test_retry_works(): mock = MagicMock() mock.side_effect = [Exception(), Exception(), 'success'] result = retry_operation...