How Self-Healing Tests Work with Shiplight AI Fixer for Dynamic UIs

Modern UIs are built to change. Teams ship component refactors, redesign navigation, swap component libraries, and roll out experiments behind feature flags. The product improves, but end-to-end tests often get worse.

That failure pattern is familiar: the user journey still works, yet CI goes red because a selector went stale, a button moved containers, or a dynamic list re-rendered with different attributes. In highly dynamic front-ends, the problem is not that teams do not know how to write selectors. It is that selectors are the wrong “source of truth” for what you are actually trying to validate.

Shiplight AI is designed around a different premise: tests should describe user intent, and the system should do the work of staying attached to the UI as it evolves. That is the practical meaning of self-healing in Shiplight, and it is why Shiplight pairs on-the-fly healing with an AI Fixer workflow for the cases automation should not guess at.

Why dynamic UIs break traditional test automation

Dynamic UI behavior is not limited to animations or loading states. It shows up in the structural habits of modern front-ends:

• DOM churn from component abstractions: A “small” refactor can replace entire subtrees, invalidating XPath and brittle CSS chains.
• Generated attributes and class names: CSS-in-JS and build-time optimizations can make classes non-deterministic across builds.
• Conditional rendering: Feature flags, permissions, localization, and experiments change what appears and where.
• Virtualized lists and infinite scroll: The element you clicked yesterday may not exist in the DOM until it is scrolled into view.

Traditional tools treat these as failures of the test. Shiplight treats many of these as normal UI evolution and focuses on preserving the test’s original meaning.

Intent-based execution is the foundation

Shiplight tests are created from natural language intent rather than brittle scripts. Under the hood, Shiplight runs on top of Playwright, which means you still get real browser execution and proven automation mechanics, but with an intent layer that makes tests resilient to DOM and UI changes.

A simplified intent-based test might look like this:

goal: Verify a user can log in and reach the dashboard
statements:
- intent: Navigate to the login page
- intent: Enter "qa.user@example.com" in the email field
- intent: Enter the password for the QA user
- intent: Click the Sign In button
- VERIFY: the dashboard shows the user's name


The point is not “YAML versus code.” The point is that the test describes what the user is doing, not how the DOM happens to be shaped today.

The intent-cache-heal loop that makes self-healing trustworthy

Pure AI-driven execution sounds attractive until you need to gate merges and releases. If a model is re-interpreting every click on every run, teams rightfully worry about determinism.

Shiplight’s approach is to make intent the source of truth, then use cached locators for fast replay, and only bring AI into the loop when reality changes. Shiplight calls this the Intent, Cache, Heal pattern.

Here is what that means in practice.

Intent: capture the semantic goal of the step

Each step retains a human-readable description of the intended action (for example, “Click the Save button”). That semantic context is what makes later healing possible.

Cache: run deterministically when the UI has not changed

When a step succeeds, Shiplight can store the resolved locator as a cache. On subsequent runs, Shiplight tries the cached locator first, making execution behave like traditional automation in the common case.

Shiplight describes this explicitly as treating locators as a cache, not a contract.

Heal: fall back to intent only on cache miss

When the cached locator fails, Shiplight falls back to AI-based resolution using the original intent and the live page context, then updates the cache once the correct element is found.

This “two-speed” model is central to why self-healing works for dynamic UIs without slowing everything down. Shiplight notes that cached locator execution is deterministic and fast, while AI re-resolution is triggered only when needed.

What self-healing looks like in dynamic UI scenarios

Self-healing is easiest to appreciate in the changes that happen every week in real products:

• A button label changes (for example, “Create” becomes “New Project”): the cached locator may fail, but the intent still matches the user-facing action, so the system can re-resolve and continue.
• A component moves to a new container during a layout refresh: position-based selectors break, but intent-based matching can still find the correct control in its new location.
• A library migration rewrites markup: DOM structure changes are exactly where intent-driven healing outperforms rule-only fallback strategies, because the intent carries semantic context that is not tied to a specific DOM shape.

This is also where many “self-healing” tools quietly create new problems: if healing is too eager, you get false passes. Shiplight’s intent-first plus cached replay model is meant to keep AI as the safety net, not the default driver.

Where Shiplight AI Fixer fits for the hard changes

Not every failure should be auto-healed. Sometimes the UI changed because the product behavior changed. Sometimes the test intent is now ambiguous. Sometimes a step needs to be rewritten, not repaired.

That is where Shiplight AI Fixer comes in. Shiplight’s platform positions auto-healing for routine UI drift, and AI Fixer for “the rest,” meaning the complex cases where you want guided repair rather than silent guesswork.

In practice, this gives teams a cleaner operating model:

• Let the system automatically heal the safe, superficial changes that should never have created work.
• When healing cannot be done confidently, route the failure into an explicit fix workflow so a human can confirm intent and update the test accordingly.

Practical tips to get the most out of self-healing on dynamic UIs

Self-healing reduces maintenance, but strong tests still start with clear intent. A few patterns help significantly:

• Write intent steps the way you would review behavior in a PR. If a step is unclear to a teammate, it will be harder for any system to resolve reliably later.
• Prefer user-visible cues in intent (labels, roles, page meaning) over implementation language (“click the div in the left container”).
• Keep assertions meaningful. Shiplight emphasizes AI-powered assertions that consider UI rendering, DOM structure, and execution context, which is especially important when the UI is dynamic and “element present” does not guarantee the page is correct.

The outcome: less maintenance, more reliable gates

Self-healing should not mean “AI improvises your test suite.” It should mean your team stops paying a daily tax for normal UI evolution, while keeping execution reliable enough to trust in CI.

Shiplight’s intent-based approach, locator caching, and heal-on-miss behavior is designed specifically for that balance, with AI Fixer as the backstop for the changes that require a deliberate update.