Self-Healing Tests vs Blanket Retries: Which Should You Use for Flaky Tests?

Use self-healing to repair broken element locators and use targeted retries only to absorb genuine infrastructure noise; never use blanket retries to mask application or test defects. They solve different problems. Self-healing addresses one specific cause of flakiness (locators that no longer match the DOM), while retries simply run a failing test again and accept a pass if it eventually succeeds. Confusing the two is how teams end up shipping bugs hidden behind green builds.

## What each technique actually does

- **Self-healing** detects that a locator failed, finds the same element via alternative attributes, and continues, logging the substitution for review. It targets the cause.

- **Blanket retries** re-execute the whole test on any failure, up to N times. They target the symptom, regardless of why it failed.

That distinction drives everything that follows.

## Where blanket retries go wrong

Retries are seductive because they make red builds turn green with one configuration line. But they carry real costs:

- **They hide real bugs.** A genuine race condition in your product will sometimes pass on retry, so a true regression slips through.

- **They mask flaky tests instead of fixing them.** The underlying flake never gets diagnosed, so it grows.

- **They are slow and expensive.** Re-running a heavy end-to-end test three times consumes CI minutes and lengthens feedback loops.

- **They erode signal.** A suite that retries everything can no longer tell you whether the product works on the first try, which is what users experience.

## Where self-healing goes wrong

Self-healing is more surgical, but it has its own failure mode:

- **It can heal to the wrong element.** If a confidence threshold is set too low, the healer may click a different but similar control, masking a genuine UI regression.

- **It only covers locators.** It does nothing for timing races, shared state, or non-deterministic data, which are the more common causes of flakiness.

- **It can hide UI drift.** A suite quietly healing dozens of elements is signalling that the product is outrunning its tests.

## A decision framework

Match the technique to the cause:

- **Locator broke due to a cosmetic refactor:** self-healing, with the heal logged and reviewed.

- **Transient network or container start-up error at the infrastructure boundary:** a small, targeted retry is acceptable.

- **Timing or async race in the test:** fix the wait condition. Do not retry, do not heal.

- **Shared state between tests:** fix isolation. Neither technique helps.

- **Non-deterministic data or time:** freeze and seed. Neither technique helps.

The rule of thumb: retries are only ever appropriate for failures that are genuinely outside your control and outside your application's behaviour.

## How to combine them safely

Used with discipline, the two are complementary rather than competing:

1. **Let self-healing handle locator drift,** with a high confidence threshold and mandatory review of every heal.

2. **Allow at most one or two retries, scoped to infrastructure-class errors only.** Configure them so they cannot retry assertion failures.

3. **Always surface what happened.** Every heal and every retry should be visible in reporting. A green build that required three retries and five heals is not the same as a clean green, and your team needs to see the difference.

4. **Track the rates over time.** Rising heal counts mean your locators need attention; rising retry counts mean your infrastructure or tests need attention.

## The cultural risk

The deeper danger of blanket retries is cultural. Once a team learns that red builds turn green on retry, the incentive to investigate disappears, and quality decays quietly. Self-healing carries a milder version of the same risk if heals go unreviewed. The antidote in both cases is visibility: make the assistance the test received an explicit, reviewed signal rather than a silent convenience.

neart.ai builds enterprise-grade quality products in this space, and the consistent principle is that automation should make failures easier to understand, not easier to ignore.

## Takeaway

Self-healing and retries are not interchangeable. Self-healing surgically repairs locator drift; retries bluntly re-run and risk hiding real defects. Use self-healing for locators, reserve narrow retries for true infrastructure noise, fix everything else at the root, and make every heal and retry visible so green never means "green after we tried three times".