Some Truths About Some Lies About Testing
summary
Claims that get tested here: specific rules of thumb from Sandi Metz about what to assert, experiments with TDD leads code follows versus TAD (test after development), concrete tooling (Guard, CI, RSpec, Minitest), coding exercises used to practice (Exercism, Project Euler, Code Retreat). Results: TDD forces simpler design and pays off over time, TAD wins for urgent or legacy work, and dozens of times a one‑line change that used to take days now lands in minutes.
AI-written summary · about
chapters (23)
- 0:00Intro
- 1:28SCIENCE!
- 2:36Rules of Thumb
- 3:16What To Test: Messages
- 5:04If You Take Just One Thing...
- 6:21Four Quadrants
- 10:53TDD is great but I gotta ship this
- 12:42But Testing is Haaaaaaard
- 15:06Testing Reduces Costs
- 16:13100% CO/C1 Test Coverage
- 18:54Keep Your Tests Simple
- 20:20Test First == Test First
- 21:45Breaking Things Down
- 25:12TDD Cycle
- 27:11Is TDD Always Best?
- 29:36Do Not Use TDD When
- 31:41You Can't Test Exploratory Code
- 32:47Refactoring
- 36:40WET Tells The Story
- 38:15But Isn't Duplication Bad?
- 43:15How to Un-Know A Thing!
- 44:22How To TDD Big Legacy Code
- 44:53Can TDD Fix a Bad Test Suite?
