10 simple rules for writing great testcases
summary
Ten concrete rules for reliable tests: write tests that document actual behaviour, keep each test small and single‑purpose, use frameworks like JUnit and mocks to make tests fast and isolated, and design diagnostics so failures point to the failing line. Track and fix flaky tests because intermittent failures create a noise floor (OpenJDK aims for ~2 hours for full CI). Avoid modifying the system under test and avoid hard‑coding paths or ports; cloud and containers amplify nondeterminism, so keep test output minimal and useful.
AI-written summary · about
chapters (36)
- 0:00Introduction
- 0:34About Steve Poole
- 1:08About Stuart Marks
- 1:42How many people write code
- 1:59What to say
- 2:41Why write tests
- 3:12Make changes
- 3:36TDD exercise
- 4:16Rules
- 4:45Think before you act
- 7:01Testing and quality
- 9:00Writing more tests
- 9:11Make your tests understandable
- 10:16What happens if your test code is not well maintained
- 11:46Keep your tests small and simple
- 12:42Structure your tests
- 13:16One operation one test scenario
- 15:00Test cases with 100 assert
- 16:41Fast test only
- 16:53Test speed
- 18:36Feedback loop
- 19:59Test run fast
- 20:31Test run long
- 21:42OpenJDK
- 28:45Cloud
- 31:49Independent tests
- 33:54Dual tests
- 36:27Test storage
- 37:04Test line failure
- 39:54Steves story
- 42:49No hard coding
- 45:29Hard coding
- 46:49No extraneous output
- 47:44Test logs
- 49:19Wrapping up
- 50:44Giveaway
related talks
40mWrite awesome tests
45mTesting the untestable PART II – patterns, use cases and practices
21mTest Kitchen: A Recipe for Good Tests
46mThe Road to Reliable Automated Tests
12mThe Tester’s Guide - 6 Bad Habits You Must Break
55mUnit Testing Like a Pro - Towards a Testable Design
40mUnselfish Testing
48mHow to Stop Hating your Tests