Test automation is supposed to catch problems. But what happens when your tests break? Traditionally, a broken test means a failed build, an alert, and someone manually investigating what went wrong. That friction is real, but it forces visibility.
Newer tools promise to remove that friction entirely. The self-healing in Playwright‘s test agents does exactly that: when a locator breaks, the system fixes it automatically. Your test rewrites itself and keeps running, without human intervention or approval.
Self-healing sounds like progress, and it often works well. But it’s also a liability: it’s a change to your test that nobody approved, nobody reviewed, and nobody necessarily knows about. That automation is the feature and the risk.
The key considerations with self-healing are whether you can trust what it’s done, and when trusting it is actually the wrong call. We’ll examine both below.
A Framework for the Decision
Start with a basic principle: self-healing is safe only when you can distinguish between mechanical breakage and semantic failure.
A mechanical breakage is straightforward. The UI moved; the element is still the same thing, just somewhere else. The button labeling “Submit” got a new ID. The self-healing engine rewrites #btn-submit to button:has-text(“Submit”). The change is syntactic. The behavior is unchanged. Review and trust it.
A semantic failure is different. The button moved because the entire flow changed. What used to be at step three is now step five. Or it’s gone entirely, replaced by something the product owner deliberately removed. Self-healing can still fix the locator. It will find some button that matches the description you gave it. But now you’re testing the wrong thing, and your test passes in silence.
That distinction (mechanical versus semantic) is the hinge on which your framework turns.
When to Use Self-Healing
You should use self-healing when:
- Your UI changes are cosmetic. I.e. redesigns, ID regenerations, class shuffles. The locator breaks, but the application logic doesn’t.
- You have a high-quality test failure signal. If a broken locator produces a clear, immediate failure in CI, human eyes see it before self-healing runs. You can investigate the repair before it merges.
- Your test is declarative enough. A test that hunts for “the button next to the input labeled ‘Password'” is more robust against self-healing than one targeting a magic ID from your framework.
- The self-healing engine provides evidence. Before you enable self-healing, ask what happens when a repair is made. Is it logged? Can you audit the decision? Does the tool distinguish between high-confidence and speculative repairs?
The Hidden Challenges of Self-Healing
Self-healing works best when humans stay in the loop. A person should review, approve, and own the outcome of every repair. When humans stay in the loop, they should confirm the following criteria:
- Is this the right business process?
- Are the assertions meaningful?
- Did the test prove the expected outcome?
- Should this generated test become part of the official suite?
- Is it safe to run in CI/CD or use for release decisions?
With that said, there are still scenarios where turning it off entirely makes sense. Turn self-healing off (or at least review every repair) when:
- Your test is vague. If your locators are brittle or depend on fragile selectors (nth-child, position-based), self-healing can “fix” them by silently finding the wrong element.
- Your application’s domain is safety-critical or tightly regulated. A test rewrite without human approval is a liability; you need a paper trail.
- You’re in the middle of a feature pivot. When product direction is in flux, self-healing can hide regressions you actually need to know about. A broken test might be telling you something important.
The Evidence Standard
Good self-healing engines behave like good debugging tools and show their work. Before you enable self-healing, ask these key questions:
- Does it log what it changed and why?
- Can you see the repair in a pull request before merge?
- Does it distinguish between high-confidence and speculative repairs?
- Can you audit its decisions retroactively?
If a tool can’t show you what it changed and why, the problem is the implementation, not the feature.
Beyond Self-Healing Locators
This same framework applies beyond Playwright. Any automated repair (whether it’s a broken selector, a stale mock, or a degraded assertion) lives in the same tension: speed and safety, automation and approval.
The Leapwork Continuous Validation Platform solves this through its Deterministic by Design architecture: AI handles adaptation and learning at authoring time, and tests change as your application changes. Meanwhile, execution remains deterministic, auditable, and governed. Nothing moves into production without becoming explicit, reviewable logic.
For teams already using Playwright, Leapwork Play brings this governance to your test suite. When self-healing is needed, it stops to flag uncertainty rather than proceeding with a guess. Repairs become explicit, traceable decisions; not silent rewrites. You keep Playwright’s speed and add the auditability that matters.
