So you're the one who got QA dumped on you. The previous QA lead left, the contract testers were cut, and now the backlog of flaky Cypress specs is your problem. Welcome. This post is for you.
We keep hearing the same thing from developers in your seat: the issue isn't writing tests, it's maintaining them. Most of the hours a small team loses to E2E don't go into writing new assertions, they go into fixing selectors that broke because someone renamed a div or shipped a design-system refactor. That's the tax. Self-healing selectors are how Lastest stops you paying it, and this post explains exactly how they work under the hood.
This is a technical explainer of the 7-layer selector chain that powers Lastest. No marketing. Just how self-healing selectors work for developers, why the chain is more robust than "ask an LLM to write Playwright," and how you'd contribute a new layer if you wanted to. Want the shorter version first? See Self-Healing Selectors, Explained.
Why "smart XPath" is not enough
The naive answer to flaky tests is "use better selectors." Pick stable attributes, avoid nth-child, prefer roles. Fine advice until your design system ships a refactor and 400 tests go red at once.
The next naive answer is "let an LLM generate the Playwright for you." We tried this. Hard. The problem is that LLM-generated test code loves to assert against whatever's visible in the HTML it was shown - which, in a modern app, means className="flex items-center gap-2 rounded-lg bg-slate-900/10". That selector has a half-life of about one PR. Bare LLM codegen also tends to need several attempts before a non-trivial flow even passes once, and the version that finally goes green still binds itself to Tailwind classes that rot on the next redesign.
There's a quality floor here worth naming too. Industry surveys consistently report that developers use AI coding tools far more than they trust the output, and AI-co-authored code tends to carry more review-worthy issues than hand-written code. If you're going to ship autonomous test authorship, you need guardrails that don't depend on the model being right. (Lastest's broader answer to that is a single human-in-the-loop review seam; this post is about the selector half of it.)
So we built the guardrail as a chain.
The 7-layer chain, in order
When Lastest records an interaction, it doesn't save one selector. It saves a bundle - a prioritized set of seven locators, any of which can identify the same element. At replay time, the runner walks the chain from most-stable to most-forgiving and uses the first one that resolves to exactly one match.
Layer 1: data-testid
If the element has a data-testid, we use it. This is the gold standard: it's explicit, it's not tied to visual design, and when it's present it almost never changes without intent. If your codebase already has test IDs, the chain basically never falls past layer 1.
Layer 2: id
HTML id attributes are the next best thing. They're unique by spec, they're semantic, and form libraries tend to generate them automatically. The catch: frameworks sometimes hash them (id="mantine-r3k"), which is why this is layer 2 and not layer 1 - hashed IDs are a trap that looks stable.
Layer 3: ARIA role
Roles are the accessibility tree's answer to "what is this thing?" A button is a button whether it's a <button>, a <div role="button">, or a styled anchor. Role-based lookup survives markup refactors because it tracks semantics, not tags. Bonus: if your app is accessible, your tests get more robust for free.
Layer 4: aria-label
Role alone isn't enough when there are twelve buttons on screen. aria-label (and its friends aria-labelledby, title) disambiguate. "Button labeled Save" is a locator that survives re-skins, component library swaps, and even language changes if you localize your labels properly.
Layer 5: Text content
Now we get into visual territory. Layer 5 is "the element whose rendered text is X." This is how a human would describe it: "click the button that says Submit." It's surprisingly robust - product copy changes less often than CSS - and it's the first layer that doesn't need any attributes at all.
Layer 6: CSS selector
Only now, six layers deep, do we fall back to a generated CSS selector. And even here we're careful: the selector is computed to be the shortest unique path using structural attributes (tag, nth-of-type, ancestor roles) while deliberately ignoring utility classes like Tailwind's. We'd rather have main > section:nth-of-type(2) button than .bg-slate-900\/10, because the former breaks only on real structural change.
Layer 7: OCR on rendered pixels
This is the one people don't expect. If layers 1-6 all fail, Lastest takes a screenshot of the viewport and runs optical character recognition over it, then clicks the pixel region whose recognized text matches what we recorded.
Why does this matter? Because a shocking amount of modern UI is not in the DOM. Charting libraries draw into <canvas>. Icon systems inline SVG with no accessible text. Map components, PDF viewers, WebGL dashboards, Figma-style editors - none of their "elements" exist as queryable nodes. DOM-based selectors cannot find the "Export" label inside a canvas. OCR can. It's the layer that lets you test the untestable.
The fallback algorithm
Here's the loop, stripped of error handling and telemetry, so you can see the shape of it:
async function resolve(bundle, page) {
for (const layer of ORDER) { // testid, id, role, aria, text, css, ocr
const locator = bundle[layer];
if (!locator) continue;
const matches = await query(page, layer, locator);
if (matches.length === 1) {
report({ layer, healed: layer !== bundle.primary });
return matches[0];
}
}
throw new SelectorNotFound(bundle);
}Two things to notice. First, we require exactly one match at each layer - ambiguous matches fall through instead of guessing. Second, when a non-primary layer resolves, we log a healed event. That's how the dashboard shows you "this test would have failed under raw Playwright, but layer 5 caught it." Over a sprint, that log becomes a map of which parts of your UI are churning and which parts are stable.
Why this beats LLM-generated Playwright
Let's compare directly. An LLM pipeline produces one selector per interaction, usually tied to whatever was in its context window. When it breaks, you re-run the LLM, it generates a different selector, and you hope. There's no chain, no memory of why the element was unique, and no fallback that doesn't involve another API call.
The Lastest chain is deterministic. The same bundle resolves the same way every run, and when it heals it heals predictably - you can see exactly which layer took over. This is the difference between "the AI fixed it" and "the test framework has a correctness model." We care about the second one.
One more thing worth stressing: this chain runs at replay time, and replays are zero-token. The AI only spends tokens when you create or fix a test. The healing logic itself is plain deterministic code, so you can re-run a healed suite thousands of times a day for $0 in model spend. Self-hosted, your screenshots and replays are unlimited regardless of volume.
It also composes nicely with the record-to-code workflow. When you record a flow, we emit real, readable Playwright - not a wrapper, not a DSL, actual page.getByRole(...) calls. The healing chain runs underneath that code at replay time, so if you want to edit the generated test by hand, you can, and you still get the self-healing behavior for free. The same locators are reachable from the MCP server (around 20 AI tools) so coding agents like Cursor or Claude Code can drive Lastest directly. For more, see the developers-doing-QA guide.
Where OCR earns its keep
A partial list of things we've seen OCR rescue in the wild:
- Chart tooltips rendered into Canvas by Chart.js and Recharts
- SVG icon buttons with no
aria-labeland no text node - Map pins in Mapbox GL / Leaflet where the "element" is a WebGL draw call
- PDF preview panes where the "Next page" control is baked into an image
- Rich text editors (TipTap, Slate) where formatting toolbars use pure icons
- Code editors (Monaco) where syntax-highlighted tokens aren't real DOM nodes at the position you think they are
If you're building a Next.js app with any of these - dashboards, editors, data viz, maps - you will hit cases where DOM selectors simply don't have anything to grab. OCR is the escape hatch.
Contributing an 8th layer
Lastest is open source (FSL-1.1-ALv2) and self-hosted. docker-compose up -d and you have it. Which means if you want to add a layer, you can.
The contract for a new layer is small:
- A capture function that, given a DOM element at record time, returns a serializable locator (or
nullif the layer doesn't apply) - A resolve function that, given a page and that locator, returns a list of candidate matches
- A priority slot in the
ORDERarray - most-stable to most-forgiving
Ideas we'd merge tomorrow: a vector embedding layer that matches elements by a CLIP-style screenshot embedding (great for icon buttons across redesigns), a DOM path hash layer that survives prop reordering, or a computed style layer for components identified by their visual role (primary button vs ghost). If you build one, open a PR against las-team/lastest. We review everything.
The bottom line on self-healing selectors
You got QA dropped on your desk. You don't have time to babysit selectors every sprint. The 7-layer chain exists so that when the design system ships v2 and every class name changes, your tests heal instead of breaking. When someone moves a button inside a canvas-based editor, OCR catches it. When an LLM would have confidently generated .bg-slate-900/10, a deterministic chain gives you getByRole('button', { name: 'Save' }) plus six backup plans.
That's the whole pitch. Self-healing selectors aren't magic, they're a fallback list with good defaults and one weird trick at the bottom. The whole thing is open source under FSL-1.1-ALv2 and free to self-host forever - docker-compose up -d, point it at your app, unlimited screenshots and replays on your own infra. If you'd rather skip the ops, Lastest Cloud runs it for a flat $299/month with no per-seat or per-screenshot fees.
Start here: clone las-team/lastest on GitHub, run it against your app, and watch the healed-layer log fill up. You'll learn more about your UI's real stability in a week than a year of flake triage would teach you. (And if you want the wider context on why this maintenance tax exists, read The Developer QA Tax.)