A follow-up to “The Test Pyramid — Reimagined.” Start with the opener if you missed it. Every testing model in popular circulation — the pyramid, the trophy, the honeycomb, the diamond, the four-layer version I just spent six posts on — has one load-bearing assumption that almost nobody states. Developers and testers actually talk to each other. Not “report […]
Part 6 of “The Test Pyramid — Reimagined.” Start with the opener if you missed it. System tests are the tests you should hate needing, write anyway, and keep on the shortest possible leash. That’s the entire post in one sentence, but I’m going to spend the rest of it convincing you that the three clauses are
Part 5 of “The Test Pyramid — Reimagined.” Start with the opener if you missed it. Most of what your team calls “API tests” are integration tests in a hat, paying rent above the deployment line that they don’t owe. I don’t mean that as a roast. I mean it as a diagnosis, and the diagnosis explains why so
Part 4 of “The Test Pyramid — Reimagined.” Start with the opener if you missed it. There is one line in your test diagram that separates the tests that cost almost nothing from the tests that cost almost everything. Most teams know this line exists. Almost no team draws it. That’s the entire problem. The deployment line
Part 3 of “The Test Pyramid — Reimagined.” Start with the opener if you missed it. There is one layer in your test suite that gives you more product confidence per line of test code than any other. Most teams barely write any of it. That layer is integration tests, and most teams have so few of
Part 2 of “The Test Pyramid — Reimagined.” Start withthe opener if you missed it. Most of what your team is writing in Selenium today should be a unit test, and you don’t believe me yet. Stay with me. I’m going to walk you through it, and by the end of this post I think you’ll at
This is the opener for a series called “The Test Pyramid — Reimagined.” Each layer gets its own follow-up post. Links will land here as they go live. 1. Unit Tests – Your Code’s Loudest Critic2. Integration Tests – Reclaiming the Middle3. The Deployment Line – The Line You Forgot To Draw4. API Tests –
I want to tell you about a test framework. It was beautiful. It had a custom DSL that read like English. Every Selenium action was wrapped in a helper that handled retries, logging, and screenshots automatically. We had a single custom RSpec matcher that every line of every test ran through — uniform syntax everywhere,
The SDET role comes with a built-in awkwardness most people never name out loud. A developer writes code. You find what’s wrong with it. You write that down somewhere — a bug report, a Slack thread, a code review comment — and now it exists, in writing, that the thing they spent two days building
There comes a point in every SDET’s career where the muscle memory has set in. You can spin up a new Playwright project before lunch. You can fix a broken locator in your sleep. You wrote the team’s page object pattern and people still mostly follow it. The framework hums. The suite is green. You