Intent-Cache-Heal Pattern

Intent-cache-heal is a deterministic execution pattern for AI-native E2E testing: the test author records user intent, the runtime caches a fast deterministic locator for each step, and AI resolution is invoked only when the cached locator fails. Combines the speed of script-based tests with the survivability of intent-based ones.

In one sentence

Intent-cache-heal stores three things for every test step — the user's intent, the most recent cached locator, and a healing path when the cache misses — so tests run as fast as scripted ones on the happy path and survive UI change like intent-based ones when the cache invalidates.

Why the pattern exists

Two common AI-test failure modes:

  1. Pure script — fast, deterministic, but breaks on every UI change.
  2. Pure AI resolution — survives UI change, but slow and non-deterministic. Re-resolving every step on every run produces flaky timing and high cost.

Intent-cache-heal sits between them: cache for the happy path, AI for the cache-miss path.

Three layers

LayerWhen it runsWhat it does
IntentAuthoring timeRecords what the user is doing, not which selector to use
CacheEvery run, default pathResolves the step using the previously cached locator
HealWhen cache miss is detectedAI re-resolves the correct element from intent and updates the cache

The first run authors the cache. Subsequent runs hit the cache directly — full script-level speed. When a real UI change invalidates the cache, the heal layer re-resolves and the test self-repairs.

Why "cache" is the right mental model

A cache is a deterministic shortcut to a slow ground-truth computation. In testing, the ground truth is "the element the user intends to interact with"; the cache is the locator that worked last time. When the locator stops working, the cache is invalidated — same model as a CDN cache invalidating on origin change. See locators are a cache for the long form.

Production properties

  • Determinism on the happy path — repeated runs against unchanged UI use the same cached locator.
  • Observable heals — every cache invalidation produces a diff that surfaces in test artifacts; humans can review changes.
  • Bounded AI cost — AI resolution runs only on cache miss, not every step every run.
  • Speed parity with scripted tests — typical AI testing tools spend 80%+ of runtime on resolution; intent-cache-heal collapses that to <5%.

What intent-cache-heal is not

  • Not the same as locator-fallback "self-healing" — those try alternate selectors. Intent-cache-heal re-resolves from user intent.
  • Not a workaround for non-deterministic UIs — flake from real timing or environment issues still requires direct fixes.

Related terms