Self-Healing Tests
Shopify stores change constantly. Theme updates, app installations, and content edits alter the DOM in ways that can break test selectors without breaking actual store functionality. Revenue Shield's self-healing system handles this automatically.
The Problem With Static Tests
Traditional automated tests rely on CSS selectors, XPath expressions, or other locators to find elements on a page. When a store's theme is updated or a new app is installed, these locators can change even though the underlying functionality still works. A button that was .btn-add-to-cart might become .product-form__submit after a theme update. The add-to-cart function still works, but the test fails because it cannot find the element.
Without self-healing, this creates two problems: false alerts that erode trust in the monitoring system, and manual maintenance work to keep tests up to date.
How Self-Healing Works
When a test fails, Revenue Shield's self-healing engine runs an analysis before sending an alert:
- Failure classification — The system examines the failure to determine whether it is a locator mismatch (the element exists but with a different selector) or a genuine functional failure (the element or functionality is truly missing).
- AI-powered element matching — If the failure appears to be a locator issue, the AI analyzes the current page DOM to find the element that most closely matches the original target. It considers element type, text content, position, surrounding context, and ARIA attributes.
- Selector update — When a confident match is found, the test script is automatically updated with the new selector.
- Verification run — The updated test is re-executed immediately to confirm the fix. If the test passes, the update is committed and no alert is sent. If it fails again, the failure is treated as genuine and an alert is dispatched.
What Gets Healed vs. What Gets Alerted
The self-healing system is deliberately conservative. It only corrects failures that are clearly caused by selector changes, not functional failures.
| Scenario | Action |
|---|---|
| Button exists but has a new CSS class | Self-heals, no alert |
| Button has moved to a different position on the page | Self-heals, no alert |
| Button is completely missing from the page | Alert sent |
| Page returns a 404 or 500 error | Alert sent |
| Cart does not update after add-to-cart click | Alert sent |
| Checkout page fails to load | Alert sent |
| JavaScript error prevents page interaction | Alert sent |
Healing Log
Every self-healing event is recorded in the healing log, accessible from the dashboard under Tests → Healing History. Each entry includes:
- The test that was healed
- The original selector that failed
- The new selector that was applied
- The timestamp of the healing event
- The verification run result (pass or fail)
The healing log gives you full visibility into what the system has changed, even though no action is required from you.
Why This Matters
Self-healing is what makes Revenue Shield a zero-maintenance monitoring system. Without it, you would need to manually update test scripts every time your store's theme changes, which defeats the purpose of automated monitoring. With it, your tests stay accurate through routine store updates while still alerting you to genuine checkout failures.
Self-healing ensures that you are only alerted when something is actually broken, not when something has merely moved.