Stop Fixing Broken Locators with AI Self-Healing
Let your Android and iOS tests heal themselves — automatically, at runtime.
AutoHeal detects broken element locators at runtime, repairs them with 90–95% accuracy, and keeps your Android and iOS automation green — without rewriting a single test.
Without AutoHeal
driver.findElement(
By.id("input_password")
);
// 💥 NoSuchElementException
// locator id="input_password"
// not found on page
With AutoHeal
Map<String,String> p = new HashMap<>();
p.put("locator", "input_password");
String healed = (String) driver
.executeScript("mobile:heal:locator", p);
// ✅ id="input_password"
// → id="txt_password_field"
Locator drift is the #1 reason mobile suites flake.
A developer renames a resource ID. A class name shifts after a refactor. An iOS accessibility label changes for a localisation pass. Your overnight regression goes red — and a QA engineer spends the morning hunting for one-line fixes.
AutoHeal sits inside your Appium driver and watches every locator. When an attribute drifts, it scans the live page hierarchy, finds the most likely match using the element's stored fingerprint, and returns the new locator at runtime — keeping your test green.
You enable it with a single capability. No rewrites, no DSL, no custom framework.
What gets healed
ID, name, class, text, accessibility ID — when only the value drifts.
XPath / CSS selectors that break because of small DOM-tree shifts.
Same self healing engine for Android (UIAutomator2) and iOS (XCUITest) — tested on real hardware, not simulators.
One capability flag, four invisible steps
AutoHeal runs inside your existing Appium driver. Your test code barely changes.
Enable the capability
Add autoheal: true to your Appium DesiredCapabilities. No SDK install.
First run baselines
On the first successful run, AutoHeal stores a fingerprint of every element your test touches.
Drift is detected
On later runs, if a locator no longer resolves, AutoHeal scans the live page for the closest match.
Healed locator returned
The new locator is returned via mobile:heal:locator so your test step continues — no failure, no flake.
See AutoHeal on the wire
Three surfaces matter — the capability, the heal endpoint, and the dashboard that tells you what was repaired.
DesiredCapabilities caps = new DesiredCapabilities(); caps.setCapability( "autoheal", true );
No new dependency, no rebuild — just an extra capability on your Appium driver.
Map<String,String> p = new HashMap<>();
p.put("locator", "input_password");
String healed = (String) driver
.executeScript(
"mobile:heal:locator", p
);
Wrap your locator lookup once. AutoHeal returns the original — or the repaired one.
Per-run heal log so engineers can review and promote repairs back into source.
Drop into your existing test code
Three lines: enable the capability, wrap your locator lookup, use it. That's the entire integration.
// 1. Enable the capability
DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("autoheal", true);
// 2. Wrap your locator lookup
public String getHealedLocator(String original) {
Map<String,String> p = new HashMap<>();
p.put("locator", original);
return (String) driver.executeScript(
"mobile:heal:locator", p
);
}
// 3. Use it in your test
String loc = getHealedLocator("input_password");
driver.findElement(AppiumBy.id(loc)).sendKeys("•••");
# 1. Enable the capability
caps = {"autoheal": True, "platformName": "Android", ...}
driver = webdriver.Remote(APPIUM_URL, caps)
# 2. Wrap your locator lookup
def healed(original: str) -> str:
return driver.execute_script(
"mobile:heal:locator", {"locator": original}
)
# 3. Use it in your test
loc = healed("input_password")
driver.find_element(AppiumBy.ID, loc).send_keys("•••")
// 1. Enable the capability
const caps = { autoheal: true, platformName: 'iOS', /* … */ };
const driver = await wdio.remote({ capabilities: caps });
// 2. Wrap your locator lookup
const healed = (locator) =>
driver.execute('mobile:heal:locator', { locator });
// 3. Use it in your test
const loc = await healed('input_password');
await (await driver.$(`#${loc}`)).setValue('•••');
Works with your existing locators
AutoHeal supports every common Appium locator strategy on both platforms — no special selector syntax.
Platforms & app types
Locator strategies
Honest about where it shines
AutoHeal is a runtime safety net for locator drift — not a replacement for fixing genuinely broken UI flows.
Use it for
- Suites that run against frequently changing builds
- Transitional periods after a UI refresh or refactor
- Renamed resource IDs, accessibility labels, or DOM tweaks
- Cross-platform suites where small differences drift over time
Not designed for
- Brand-new UI components that didn't exist before
- Major visual or structural redesigns of a screen
- First runs — AutoHeal needs a successful baseline to fingerprint elements
- Hiding genuinely broken flows from your team
Everything you need to stop the flake
Healing accuracy
On supported attribute and property changes for indexed elements — measured across thousands of real-device runs on Android and iOS.
Healing happens inside the test run — no offline rewrites, no PR cycle, no overnight failures.
See exactly which locators were healed and to what — auditable before/after for every repair.
All common locators
ID, XPath, CSS, accessibility ID, class, name, text, tag.
No framework lock-in
Appium · TestNG · JUnit · PyTest · WebdriverIO.
Opt-in by capability
Toggle per job — only enable healing where it helps.
Self-improving baseline
Each run refreshes element fingerprints.
Frequently asked questions
What is a self healing agent in test automation?
A self healing agent is an AI component that sits inside your test execution layer and automatically repairs broken element locators at runtime. Instead of failing a test when an ID, XPath or accessibility label changes, it scans the live page, finds the most likely match using a stored fingerprint of the element, and returns the new locator so the test step continues — no engineer triage required.
How does AutoHeal fix broken Appium locators automatically?
AutoHeal stores a fingerprint of every element your test touches on the first successful run. On later runs, if a locator no longer resolves, it inspects the live UIAutomator2 or XCUITest page hierarchy, scores candidate elements against the stored fingerprint, and returns the best match through the mobile:heal:locator Appium endpoint — all in-flight, with no test rewrites.
How is self healing test automation different from traditional test maintenance?
Traditional maintenance is reactive: a build goes red, an engineer opens the test, finds the changed locator, edits source, raises a PR, waits for CI. Self healing is proactive — the locator is repaired the moment drift is detected, the run stays green, and engineers review repairs from a heal log instead of debugging overnight failures.
Can the self healing agent work on real Android and iOS devices?
Yes. AutoHeal runs on Pcloudy's 5,000+ real Android and iOS devices — not emulators or simulators. The same healing engine is used across UIAutomator2 (Android) and XCUITest (iOS), so cross-platform suites benefit from identical behaviour on real hardware.
What types of locator changes can AutoHeal repair?
Attribute changes (ID, name, class, text, accessibility ID where only the value drifts), small DOM-tree shifts that break XPath or CSS selectors, and renamed resource IDs after refactors. It will not invent locators for brand-new elements or fully redesigned screens — those still need a code change.
Is self healing test automation suitable for banking and fintech app testing?
Yes. BFSI teams use AutoHeal to keep nightly regression suites green across frequent compliance-driven UI updates, while every repair is logged with a before/after locator and timestamp — giving auditors a clear trail of what changed, when, and on which device.
How does AutoHeal integrate with existing Appium test suites?
Add autoheal: true to your DesiredCapabilities and wrap your locator lookups with the mobile:heal:locator script. Your existing TestNG, JUnit, PyTest, WebdriverIO or NUnit suites stay intact — no SDK install, no DSL, no custom framework. Java, Python, JavaScript, C# and Ruby are all supported through Appium's standard executeScript call.
What is the difference between self healing and flaky test detection?
Flaky test detection identifies tests that pass and fail intermittently so engineers can investigate them. Self healing actually repairs the underlying cause — broken locators — at runtime. The two are complementary: detection tells you which tests are unstable, healing keeps the rest of the suite running while drift is happening.
