Locator repair (self-healing)

How it works

UI tests break constantly on harmless changes: a renamed CSS class, a reordered list, a new wrapper element. Self-healing tools, offered in commercial test platforms for several years though with little independent evidence of how well they work, record several attributes for each element when a test passes — text, role, position, neighbours, attributes. When the primary locator fails, they score candidate elements on the page against that fingerprint and use the best match if it's close enough. Newer variants add a model that reads the page and the test step's intent ("click the submit button on the payment form") to choose. Many tools heal at runtime and move on; good practice is to flag every heal and hold the merge until someone has approved the new locator as a code change.

When to use it

Large UI suites where locator breakage dominates maintenance; products with frequent front-end refactoring; and as a stopgap while the front end adopts stable test IDs.

Limitations

A healed test can pass on the wrong element: if the button moved because the design changed, clicking whatever now looks most similar may hide a real regression. Silent healing turns locator problems into invisible drift. It treats a symptom — the real fix is stable, semantic locators such as roles and test IDs, which reduce the need for healing.

Before you reach for it

Find elements by role, label and visible text, with test IDs where those aren’t enough. Then healing only has to cover the parts of the suite not yet converted.

What you still own

Reviewing every healed locator before it becomes permanent, and fixing the underlying locator strategy.

Cite this