How do self-healing locators work, and what can go wrong?

“Self-healing” describes tools that try to recover when a UI locator no longer matches, instead of failing the test. Several commercial platforms and some open-source projects (Healenium for Selenium is a well-known open-source example) implement variants of it. Healing of individual locators is a real, shipped technique; a fully self-maintaining suite is not something I’d claim exists.

How it typically works

1. Record a fingerprint. On successful runs, the tool stores information about each located element: tag, id, name, classes, text, attributes, position in the DOM tree, neighbouring elements, sometimes visual position.
2. Detect failure. A findElement throws NoSuchElementException (or the equivalent).
3. Search for candidates. The tool scans the current DOM for elements and scores each against the stored fingerprint, using weighted attribute matching, tree-distance algorithms or a learned model.
4. Heal. If the best candidate scores above a threshold, the action continues on it. Some tools report a suggested new locator; some update locators automatically.

Stored:   <button id="submit-order" class="btn primary">Place order</button>
Current:  <button id="place-order-btn" class="btn primary">Place order</button>
          <button id="cancel-order" class="btn secondary">Cancel</button>
Result:   first candidate scores highest (same text, classes, position) -> healed

What can go wrong

• Wrong element, false pass. If “Place order” became “Save draft” in a regression and a similar button remains, the tool may click it and the test passes. A test that cannot fail when the UI is broken is worse than a failing one.
• Masked product changes. Sometimes the locator broke because the product changed in a way someone should look at: a removed button, a renamed action, an accessibility regression.
• Locator drift. Automatic updates accumulate unreviewed changes in the codebase.
• Hidden flakiness and cost. Healing adds time to failures, and inconsistent healing across runs makes results nondeterministic.
• Trust. Teams stop reading the reports, so healed events become invisible.

How I would use it safely

• Treat every heal as a warning, surfaced in the report and ideally failing the build in release pipelines or above a count.
• Require human review of suggested locator changes, delivered as a pull request rather than silently applied.
• Use conservative thresholds; a weak match should fail.
• Pair it with assertions on outcomes, so clicking the wrong button is caught by the next step.
• Fix the root cause: agree on data-testid attributes or role-based locators with developers. Most “healing” demand comes from brittle locators such as absolute XPath or generated class names.

My position

Self-healing can reduce maintenance noise in large legacy UI suites, especially during frequent cosmetic changes. It is a mitigation for locator brittleness, not a replacement for a good locator strategy, and its output must stay visible and reviewable.

What interviewers look for

• Accurate mechanism: fingerprint, candidate scoring, threshold.
• The false-pass risk stated clearly.
• Practical controls and a preference for fixing testability at the source.