Self-Healing Tests, Explained
Self-healing tests auto-repair broken element locators when the UI changes. Here's how that works, what it actually fixes, the risk of healing over a real bug, and how it differs from autonomous testing.
"Self-healing" is one of the most-marketed features in test automation and one of the most misunderstood. It's a real, useful capability with a genuinely narrow scope — and it's routinely confused with autonomous testing, which is a different thing entirely.
How self-healing works
A self-healing test is an automated test whose framework attempts to automatically repair a broken element locator when the UI changes.
When a test records a step — "click the Save button" — the tool doesn't just store one selector. It captures a bundle of signals about that element: its CSS path, its text, its id and other attributes, its position, nearby labels, its role. On a later run, if the primary selector no longer matches (the class was renamed, the DOM was restructured), the tool falls back to the other signals, scores the candidate elements, picks the most likely match, and continues the run instead of failing. Better implementations then surface the change so a human can approve an updated locator for next time.
The key point, which the marketing tends to blur: there is still a test. Someone recorded or wrote it, and it still encodes a fixed sequence of steps and assertions. Self-healing makes exactly one part of that test — finding elements — more tolerant of change. Everything else about maintaining the suite is unchanged.
What it fixes — and what it doesn't
Fixes:
- A renamed class, a new wrapper
div, or a restructured DOM that would otherwise break a selector while the user-facing element is still there. - Minor layout changes that move an element without changing its identity or purpose.
- The steady drip of "element not found" failures that make a recorded suite expensive to keep green.
Doesn't fix:
- A flow that gained or lost a step. If checkout now has an address-confirmation screen, the recorded steps are simply wrong, and no locator repair helps.
- A test that's checking the wrong thing because the feature's behaviour changed. Healing finds elements; it doesn't update assertions.
- Timing, shared-state, or third-party flakiness. Those aren't locator problems.
- The upfront work of authoring, naming, and organising the suite, or the review overhead the suite carries.
The risk: healing over a real bug
Self-healing is a heuristic, and heuristics can be confidently wrong. If a button genuinely disappeared because of a bug — a broken conditional, a failed permission check, a JavaScript error that halted rendering — a self-healing test might "helpfully" locate a different button that looks similar, click it, and pass. The regression the test existed to catch sails through green.
Good implementations flag every heal so a human can review it, which mitigates the risk but doesn't remove it — and it means a green run isn't fully trustworthy until someone has looked at what healed and why. On a large suite with frequent UI churn, that review can become its own backlog.
Self-healing vs autonomous testing
They get conflated because both involve "the tool adapting to change," but they're structurally different:
| Self-healing tests | Autonomous testing | |
|---|---|---|
| Is there a test to maintain? | Yes — recorded or written, then healed | No — the app is explored each run |
| What adapts | Element locators, within a fixed script | The whole approach, re-derived per run |
| Coverage growth | Only where a test was authored | Every run reaches more of the app |
| Handles a changed flow? | No — the steps are still wrong | Yes — it re-explores the new flow |
| Failure mode | May heal over a real regression | Reports behavioural differences between runs |
| Trust in a green run | Needs review of what healed | Green means the flows completed |
Autonomous testing doesn't heal anything because there's nothing to heal. It works out how to use the app from scratch on every run, so a renamed button, a restructured page, or an added step are all just part of the current app it's exploring. Autonomous Testing vs. Scripted Tests and the autonomous testing guide cover the distinction in full.
When each makes sense
- Self-healing is worth having if you're committed to a recorded or scripted suite and want to reduce — not eliminate — locator maintenance, and you have the capacity to review heals. Most codeless tools include it; Manta vs Testim compares one such tool directly.
- Autonomous testing makes sense if the goal is to stop maintaining a suite at all for broad coverage, keeping a small scripted set only for the exact assertions that must be precise. See test automation for QA teams.
Bottom line
Self-healing repairs broken locators inside a test you still own, maintain, and review. It helps at the margin, doesn't touch three of the four causes of flakiness, and can occasionally mask a real regression. Autonomous testing removes the maintained test entirely for broad coverage — a different, more complete answer to the same underlying problem of tests that break every time the UI moves.
Point Manta at your app — no locators, nothing to heal.