How Does TestSprite Auto-Heal Rerun Work?

Every test failure asks a question: did the product break, or did the test go stale?

Answering it is skilled work. An experienced QA engineer looks at a failed test, opens the product, tries the flow by hand, and makes a judgment: the button moved but checkout still works, so the test needs updating, or the button moved and checkout is genuinely broken, so someone needs to fix the product. That judgment call, made well, is what keeps a test suite meaningful.

Auto-Heal Rerun is TestSprite making that judgment call automatically, on every failure, before the result ever reaches you. Here's what actually happens inside one.

What Triggers It

Auto-Heal Rerun, available on the Standard plan and above, activates when a test fails. Not on every run, and not as a blanket retry policy. It responds specifically to the situation where a previously working test stops passing.

That situation has two possible causes, and they demand opposite responses. If the product regressed, the failure must surface loudly and immediately. If the UI merely drifted, a component renamed, a layout reorganized, an element moved, the failure is noise, and surfacing it costs an engineer an investigation that ends in "the product was fine."

The whole design of Auto-Heal Rerun is refusing to treat those two cases the same way.

The Judgment: Behavior, Not Structure

When a test fails, the agent's question isn't "can I find the element again?" It's the question the QA engineer would ask: does the product still deliver the correct outcome for the user?

Other verification tools read your code and guess. TestSprite opens your app and uses it.

The agent re-engages the flow in the running application the way a real user would. If the submit button was renamed and restyled but a user can still fill the form and complete the submission, the behavior is intact. The failure was structural. The test adapts to the drifted UI, the rerun completes, and the result reports what matters: the flow works.

If the user can no longer complete the flow, the form submits to nothing, the confirmation never appears, the outcome is wrong, then the behavior regressed. No adaptation happens, because adapting would mean papering over a real break. The failure surfaces with a product-level description: what action was taken, what should have happened, what happened instead.

The "Rerun" in the name is literal. The adapted test executes again, so a heal is never an assumption. It's a verified pass against the current UI.

What Auto-Heal Explicitly Does Not Do

One boundary is worth stating plainly, because "self-healing" gets used loosely across the industry: Auto-Heal Rerun adapts tests to UI drift and layout changes. It does not rewrite your application code.

When behavior genuinely breaks, Auto-Heal doesn't attempt a fix, doesn't patch around the regression, and doesn't decide on its own what the product should do. It reports. The fix belongs to your workflow: the failure description returns to the IDE through the MCP Server, and the coding agent that wrote the code proposes the repair with you in the loop.

Healing the test and healing the product are different jobs, and keeping them separate is what makes the green trustworthy. A suite that adapted itself around real regressions would be worse than no suite at all.

Why This Matters Most for AI Coding Teams

Structural drift used to be occasional. With AI coding tools, it's ambient.

A Cursor session reorganizes a component tree as a side effect of a performance pass. A Claude Code session renames elements while consolidating hooks. None of it changes what users experience, and all of it breaks structure-anchored tests. For a team running several sessions a day, a suite without behavioral judgment fails constantly, and every failure demands a human to determine it was nothing.

The arithmetic decides whether testing survives. If nine of ten failures are structural noise, engineers stop reading failures, and the tenth one, the real regression, ships. Auto-Heal Rerun changes the arithmetic: structural drift heals silently and verifiably, so the failures that reach the team are the ones worth their attention. The suite stays trustworthy at exactly the pace of change that would otherwise kill it.

A Scenario: One Failure, Two Paths Through the Same Run

A team builds a nonprofit donation platform with Claude Code. A session overhauls the donation form: the amount buttons become a slider component, the layout reflows, and the recurring-donation toggle gets renamed and moved into an options panel.

The nightly run hits the changed form, and the donation flow test fails on first execution. Auto-Heal Rerun engages.

The agent works the new form as a donor would: sets an amount on the slider, opens the options panel, enables recurring donation, submits. The flow completes, the confirmation shows the right amount and cadence, and the thank-you email fires. Behavior intact. The test adapts to the new structure, the rerun passes, and the morning report shows the donation flow green, with the heal noted rather than a false alarm raised.

The same run also fails on the receipt download test, and here the second path unfolds. The agent retries the flow: completes a donation, opens the receipt. The receipt renders, but the donation amount shows as $0.00, because the overhauled form now passes the slider value in cents and the receipt template still formats it as dollars, dividing a number that was already divided. Behavior broken. No adaptation. The finding lands with the full description: which flow, what the receipt showed, what the donation actually was.

One run, two failures, two correct judgments. The team's morning starts with exactly one thing worth fixing, and the coding agent already has the description it needs.

Conclusion

Auto-Heal Rerun works by making the judgment call that separates useful test suites from noisy ones: on every failure, it re-engages the flow like a real user, determines whether the product's behavior is intact or broken, adapts and verifiably reruns when it's drift, and surfaces a precise finding when it's real.

It adapts tests, never your application code, and it never adapts around a genuine regression. For teams whose AI coding sessions reshape the UI weekly, that judgment, made automatically and correctly, is what keeps green meaning green.

Turn on Auto-Heal Rerun with TestSprite Standard and let your suite survive your next refactor.