Self-healing test tools, compared by how they actually heal

Family one: repair the stored locator

This is what most people mean by “self-healing.” The tool keeps a record of how to find each element. When a locator stops matching, it does not give up; it looks at the live DOM and picks the element that most closely resembles the one it remembers, then substitutes that locator and continues.

Healenium is the clearest open-source example. It sits as a proxy in front of the real Selenium driver and intercepts every findElement call. It records each locator’s ID, CSS, XPath, tag, class, and text in a PostgreSQL store. When a locator throws ElementNotFound, a tree-comparison algorithm scores DOM candidates against that stored history and picks a replacement. Commercial low-code tools (Testim, Mabl) do a similar thing without a database you manage: they capture many attributes per element at record time and re-rank them at runtime so one broken attribute does not sink the lookup.

The strength is predictability. The healed locator is a real locator you could inspect. The limit is also structural: a fallback only works when a close-enough candidate still exists on the page. Rename a class and it heals. Split one screen into two steps, or relabel a button so its meaning changes, and there is no neighbor to swap to.

Family two: store no locator at all

The second family removes the thing that breaks. Instead of recording a locator and repairing it later, the test is written as intent, in plain English, and resolved against the live page every single run. There is no stored XPath, no attribute set saved in a database, and therefore no locator to rot between releases. “Healing” stops being a feature because the failure mode it patches never occurs.

Assrt is built this way. You describe a flow as a #Case block of plain steps, and the runner resolves each step against a fresh accessibility tree at execution time:

#Case 1: Checkout with a saved card
- Click the Cart button
- Click Proceed to checkout
- Verify the Place order button is visible
- Click Place order
- Verify the text "Order confirmed" is visible

Nothing in that block names a selector. “Click the Cart button” is resolved at run time by reading what is actually on the page, not by replaying a locator captured weeks ago. When the Cart button moves, gets a new class, or shifts into a different container, the next run simply reads the new tree and finds it again.

The anchor: there is no locator store in the source

You can verify the “nothing to heal” claim in Assrt’s own code rather than taking it on faith. In the open-source runner at src/core/agent.ts, the agent is instructed to capture a fresh snapshot of the accessibility tree before each interaction and to use the element refs from that snapshot, never a persisted selector. Then, in the catch block around lines 1069 to 1077, any time an action fails the code immediately calls this.browser.snapshot() again and feeds the fresh accessibility tree back to the model with the instruction to “try a different approach.”

Compare the two designs directly. Healenium’s recovery path ends in a write to its locator store (it persists the new locator for next time). Assrt’s recovery path ends in a fresh read of the page and a re-decision. One repairs stored state; the other has no stored state to repair. That single architectural difference is why the “self-healing” vocabulary, which is entirely about patching a remembered locator, does not map onto the second family at all.

One more consequence of having no proprietary store: what Assrt produces is standard Playwright. The generated tests are real .spec.ts files you commit to your own repository and run in any CI. There is no database that owns your suite and no format you would have to export out of if you left.

The two families, side by side

This is the lens the ranked lists skip. Sort by the mechanism, not the logo, and the trade-offs become legible.

How to choose, honestly

Locator-repair tools win when you already have a large Selenium suite and you do not want to rewrite it. Healenium drops in front of your existing driver and cuts the day-to-day “a class changed and now forty tests are red” tax without you touching the test code. If your investment is in Selenium and your changes are mostly cosmetic, that is the lower-friction path and you should take it.

Intent-resolution wins when you are starting fresh, when your UI changes are structural rather than just renamed classes, or when you refuse to let a vendor database hold your suite. You write intent, you keep real Playwright code, and you remove the entire class of “stale locator” failures rather than automating their repair. The honest caveat: any tool, in either family, fails when the described action no longer exists in the product. No mechanism heals a feature you deleted.

Frequently asked questions