If you've ever owned an end-to-end test suite, you know the truth:
most failures aren't real failures. They're popups. Renamed selectors. Minor layout changes.
A healthy CI pipeline can get taken down by something as innocent as a cookie consent modal.
That's why “self-healing tests” have become such a buzzy phrase in test automation circles. But behind the buzzword, there's a very practical idea: tests should be able to adapt, not just fail.
At Donobu, we've been building exactly that — on top of Playwright. This post breaks down how self-healing actually works, under the hood.
1. Detecting Failures with Context
Traditional tests fail silently and dramatically. One broken locator and your test suite is toast.
Donobu does something different.
Each test carries an objective — a short natural language description of what the test is supposed to accomplish.
When a step fails, Donobu doesn't just give up. It asks:
“Given the test's objective… can I still get this test to the finish line?”
That objective gives Flowpilot (our autonomous browser agent) a target, not just a brittle sequence of clicks.
2. Failover Selectors == Less Brittle Test
Most flakiness comes from simple selector drift.#checkout-button becomes #cta-checkout, and suddenly your pipeline is bright red.
Donobu identifies elements in a way that survives these minor changes.
We build a smart selector failover that includes:
- Attributes
- Test Ids
- DOM hierarchy & siblings
When the original selector fails, our test runner moves to the next closest match using this list. If the confidence is high enough, the test can proceed without failing. Some companies call this self-healing, but this simple selector failover is a basic level of it.
page.find("[data-testid='layout-header-learners-button']", {
failover: [
'#checkout-button',
".//button[normalize-space(.)='Checkout']",
],
})
3. When Things Break: Traditional vs Self-Healing
This is where it all comes together.
Let's look at the same test running in two worlds:
- ❌ Traditional E2E test suite
- ✅ Donobu self-healing test suite
❌ Traditional E2E Test
The popup blocks the click → the test fails → the pipeline is red → someone has to fix it manually.
✅ Donobu Self-Healing Test
Flowpilot detects the popup, figures out how to close it, retries the failed step, and updates the test.
| Traditional Test | Donobu Self-Healing Test |
|---|---|
| Breaks on minor UI drift | Recovers autonomously |
| Blocks the pipeline | Keeps CI green |
| Requires manual fix | Suggests a PR with fix |
| Brittle and reactive | Adaptive and resilient |
4. Real-Time Healing in Action
When a failure occurs, Flowpilot steps in:
- Detects the blocking UI element (e.g., a cookie consent modal)
- Figures out the minimal action required (e.g., click “Agree”)
- Executes it and retries the failed step
- If successful, rewrites the test to include the fix
- Opens a PR so you can review and merge it
// NEW → Accepting the cookie policy to ensure the page can load correctly
await page.click(".//button[normalize-space(.)='Agree']");
No flaky reruns. No manual patching. The test heals itself — and leaves a paper trail.
5. Human-in-the-Loop by Design
We never take control away from your team.
When a test heals itself:
- Donobu creates a PR with the proposed fix.
- You review and merge it like any other change.
- Your test suite stays yours — we just make it easier to maintain.
Why This Matters
The real cost of end-to-end testing isn't writing the tests.
It's keeping them alive through daily product changes.
Self-healing flips that script:
- 🚀 Faster shipping
- 🧼 Less test maintenance
- 🛡️ More stable CI pipelines
When your tests can adapt, they stop being brittle scripts — and start acting like teammates.
TL;DR
Self-healing with Donobu means:
- Each test has a clear objective.
- Flowpilot fingerprints elements and adapts to UI drift.
- Tests recover in real time and generate PRs with their own fixes.
🦸 Write once. Let your tests take care of themselves.