Selenium In the Enterprise: What went right, what went wrong (so far)
summary
Describes a shift from bulky Selenium suites to a pragmatic stack: thousands of unit tests in PHP, about 10 Selenium tests run on every deploy, and monitoring with StatsD and quarter‑million real‑time graphs to catch regressions. Claims slow Selenium runs (35+ minutes) force tradeoffs, so the team rewrites tests in the app language, uses Behat+Mink+PHPUnit, and runs lightweight checks (a Perl curl loop that fails on non‑200) to catch most problems. Emphasizes speed and recoverability over exhaustive UI proof.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 2:26Etsy’s deployment philosophy
- 10:05Early automation failures
- 15:43Large Selenium test suites
- 21:00Minimal Selenium tests and monitoring
- 25:56Functional testing complexity
- 28:25Q&A: Mink and Selenium
- 31:29Q&A: Resistance to releases
- 35:02Q&A: Selling continuous delivery
related talks
38mFreeing up Selenium
36m3 ways not to use Selenium
41mFunctional Tests (Selenium) in Practice
53mTransforming testing methodologies: From manual to robust strategies
28mOpening Keynote
37mFrom Rigidity to Resiliency: An Evolutionary Tale of Selenium-Based Frameworks
17mSurviving Growing from Zero to 15,000 Selenium Tests
19mSelenium Security Scanner