Building Quality with Foundations of Mud
summary
Practical recipe for Selenium-based quality: use Selenium Grid or a SaaS to run tests in parallel and get full feedback in about five minutes, keep CI running constantly, and enforce a near-0.01 intermittent failure rate per test. Replace flaky back ends with stubbed interfaces via an anti-corruption layer, treat stubs as first-class code, use a test data locator that can inject randomized real-like records, require immediate fixes or reverts on red builds, and pair up to debug flakiness — this yields long runs of safe continuous deployment.
AI-written summary · about
chapters (16)
- 0:00Intro
- 1:08Textbook solution
- 4:20Your test data suck
- 6:09o build quality and stay good?
- 9:30What can go wrong?
- 11:36Too slow tests?
- 15:34Too many errors ?
- 18:04Too many data errors ?
- 19:31Too many errors (2)
- 20:29Strategy 2: Stubbing
- 21:12Architecture for stubbing
- 22:17Test data for stubs
- 24:32Stubbing antipatterns
- 25:07Normalize stubs
- 26:18Live tests
- 28:58Questions?
related talks
25mHow to ensure Testing Robustness in Continuous Testing Environments
47mThe Valley of Success
33mStabilizing a Selenium build
01h 14mContinuous Testing
38mFreeing up Selenium
40mFinding Flakiness: The Real Reasons Your Tests Aren't Reliable
23mAdaptive Testing
39mBuilding The Blocks of Trust In Automation