The Secret Ingredient: How To Understand and Resolve Just...
summary
Every flaky test traces to one assumption about environment: it expects a particular state and that state sometimes changes. Three concrete failure modes appear: non-determinism (clock, random, network — freeze time or stub network with Timecop or WebMock VCR; see 1.3s vs 0.01s speed wins), order dependence (shared mutable state — use rspec --order random and rspec bisect or inject dependencies), and race conditions (parallel IO or threads — use StringIO, fibers, or isolate resources).
AI-written summary · about
chapters (11)
- 0:00Flaky tests introduction
- 2:47Defining flaky tests
- 4:37Non-determinism in tests
- 7:25Fixing tests with mocking
- 11:42Network-related flakiness
- 16:24Order-dependent flaky tests
- 21:46Debugging shared state
- 28:17Race conditions in tests
- 33:41Fixing race conditions
- 39:06Summary and cheat sheet
- 43:03Q&A
related talks
42mDon't Let Your Tests Flake Out
29mCommon Mistakes that make test cases flaky and how to avoid them
21mTaming Flaky Specs: Diagnosing Test Failures in Ruby
41mDeterministic Solutions to Intermittent Failures
36mFixing Flaky Tests Like a Detective
24mHow to solve intermittent issues, aka Random Failures
40mFinding Flakiness: The Real Reasons Your Tests Aren't Reliable
42mTesting on Thin Ice: Chipping Away at Test Unpredictability