Structure and Interpretation of Test Cases
summary
Argues that good tests are readable specifications not build ornaments, defines a unit test as behavior whose pass/fail is solely determined by test and unit, and separates unit vs integration concerns; demonstrates naming and structure with a leap year example (equivalence classes, edge cases, proleptic Gregorian rules), uses stacks and queues to show state-based given-when-then specs, warns about brittle over‑coupling and Goodharted metrics while recommending Google Test and 100% statement coverage as a starting feedback.
AI-written summary · about
chapters (21)
- 0:00Start
- 1:46Structure and Interpretation of Computer Programs
- 6:13Who Should You Be Writing the Test Book for
- 9:04Unit Testing with Test Driven Development
- 9:14Unit Testing
- 10:53Basic Minimum
- 13:29Classic Three-Way Comparison
- 14:29Unit Test
- 17:52Scheduler
- 20:40Coverage
- 22:34Path Coverage
- 34:36Meaningful Categories
- 35:38Propositional Naming Style
- 40:11Simple Cases
- 45:33Abstract Data Types
- 47:04Internal State Modeling
- 47:55Test Constructor
- 51:30The Strength of a Test
- 56:21State Model
- 1:05:05Interaction Testing
- 1:05:51Recommendations
