Effective Unit Testing
summary
Focuses on concrete rules and tradeoffs for Java/JUnit: require known fixed input and output, prefer write tests first to design APIs and catch bugs early, and aim for one assert per test and tests that run in about 1s or less. Cites a codebase at ~70% test coverage (JaCoCo) and an independent library zom at 99% coverage as examples. Warns against flakiness from time, network, randomness, and threading, and recommends CI/submit-queue and never merging when tests fail.
AI-written summary · about
chapters (16)
- 0:00Intro
- 1:45Why do we write unit tests?
- 7:19Eliminate everything that makes input or output unclear or contingent
- 13:57Why Unit Tests?
- 17:33Tests and Thread Safety
- 19:17The Two Least Known Facts of Unit Testing
- 20:462. You can have many test classes per model class.
- 21:17Speed
- 24:07Passing tests should produce no output
- 25:39Failing tests should produce clear output
- 27:16Flakiness
- 31:41System Skew
- 34:17Avoid Conditional Logic in Tests
- 37:02Refactoring
- 39:14Development Practices
- 41:53Final Thoughts
