Locators Are a Cache, Not a Contract: A Mental Model for E2E Tests That Actually Survive
Every E2E test suite I've worked on has the same lifecycle: build it, trust it for a few sprints, then watch it slowly become the thing that slows you down instead of speeding you up. The root caus...

Source: DEV Community
Every E2E test suite I've worked on has the same lifecycle: build it, trust it for a few sprints, then watch it slowly become the thing that slows you down instead of speeding you up. The root cause isn't bad tests. It's a bad mental model. We treat CSS selectors and XPath as the definition of our tests. They're not. They're a performance optimization. The problem in one sentence When a button moves from the sidebar to the header, the test fails. But the user journey — "click Submit" — didn't change. The test broke because the how changed, not the what. Traditional test automation conflates these two things: // This is "how" — breaks when the DOM changes await page.click('.sidebar > .btn-primary-submit'); What if we separated intent from implementation? The mental model: locators are a cache Think of locators like a database cache: Cache hit: The locator resolves. Test runs at full speed (~1ms per step). Deterministic. Cache miss: The locator is stale. Fall back to the intent ("clic