TDD Revisited
summary
Argues that TDD is about discovering behavior not writing isolated unit tests, rejects heavy mocking and the “100% coverage” expectation, and recommends developer tests that follow red-green-refactor to drive APIs by use cases. Uses xUnit-style tooling and mocks only for slow or shared IO (databases, third‑party services); prefers testing the use case/interactor layer in a clean/hexagonal architecture so refactoring changes implementation without breaking behavioral tests. Warns against Cucumber/specflow if customers don’t author acceptance tests.
AI-written summary · about
chapters (18)
- 0:00Start
- 1:30Key Fallacies
- 1:52Unit Testing
- 3:28Knee Driven Development
- 11:01Developer Tests
- 12:22Refactoring
- 14:36Break out of Class
- 15:17Test Principles
- 33:54User Stories
- 37:57Customers Write Acceptance Tests
- 44:31Classical Testing
- 45:56Long Feedback Loop
- 47:36Write Production Code in Response to a Test
- 53:03Testing Pyramid
- 54:24Clean Architecture
- 54:54Domain Service Layer
- 57:56Gears
- 59:43The Fallacies
