Ten things you heard about testing that might be wrong
summary
Argues that most unit test failures come from implementation changes not bugs, so tests should verify behavior not structure; warns that heavy mocking and DI cause design damage and fragile tests, advising to avoid mocking data classes and to mock only across architectural boundaries. Cites studies showing widespread flakiness (>50% of developers, ~41% at Google) and describes SoundCloud teams dropping flaky UI tests after low ROI. Recommends an 80/20 focus on high-value modules, measure coverage only to find gaps, and treat AI-generated tests as low-quality scaffolding unless carefully validated.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 3:57Change should fail test
- 9:12Testable code vs design
- 13:52Coverage ≠ quality
- 17:06Flaky tests erode confidence in testing
- 20:19Over-testing wastes time
- 25:55AI will not solve all testing problems
- 33:14Pyramid outdated?
- 37:11Summary
related talks
39mTen things you heard about testing that might be wrong
57mAdvanced Testing Techniques: Tips from the trenches
37mClean Test Code
44mHow not to test
01h 48mNo Such Thing as Manual Testing and Other Confusions
20mThe Art of Testing
47mThe secret unit testing tools no one ever told you about
01h 05mMicrotesting