DEV Community: Jim

I got tired of re-recording broken tests, so I built my own testing tool

Jim — Mon, 07 Sep 2026 02:19:33 +0000

Quick disclosure so nobody feels tricked: I built and run a no-code web UI
testing tool called CueCast. This is the story of how it went from a
personal annoyance to a shipped product — including the parts that did NOT
go well.

The moment I snapped

Two sprints in a row, I spent more time fixing recorded tests than building
the features they were supposed to protect. The last straw was a checkout
flow test that went red because someone renamed a button. The button worked
fine. The feature worked fine. The test just couldn't find it anymore.
Re-recording the whole flow took the better part of an afternoon — and it
broke again within the week.

Why recorded tests actually break

Before writing any code, I listed why recorded tests die. Three reasons
came up over and over:

1. One element, one locator. Most recorders save a single CSS or XPath
selector. The page hasn't even changed semantically — a new wrapper div, a
reordered class list — and that one string stops matching. The test reports
"failure," but the feature is fine. False alarms are worse than no alarms,
because they train you to ignore red builds.

2. The input layer lies. Many tools inject JavaScript events directly
into the page. The page reacts, but not the way it reacts to a real mouse
click. Hover states, focus traps, drag sequences, frameworks with their own
event delegation — they all behave subtly differently. Tests pass with
synthetic events and miss bugs real users hit.

3. Failures come with no evidence. A test goes red and hands you a
boolean. What did the page look like? Which step failed? Did the button
move, get covered by a modal, or never render? You re-run everything
locally to find out, which is the most expensive possible way to debug.

That list became my spec. Everything else was negotiable; those three were
the product.

Three decisions that defined the build

Decision 1: never store a single locator.

Instead of saving one selector per element, CueCast captures multiple
candidates per element — structural path, accessible attributes, visible
text — and replays them as a fallback chain. If the page changed and
candidate #1 no longer matches, #2 and #3 still hit. The test passes, no
human intervention, no re-recording.

This single decision is why replay stability is the headline feature. It's
not AI magic — it's just refusing to depend on one fragile string.

Decision 2: drive the browser through the debugger protocol, not page
injection.

We replay actions via the Chrome DevTools Protocol — the same channel
DevTools itself uses — so clicks and typing land as trusted browser input.
That means hover menus, focus behavior, and framework event handling act
the way they do for a real person.

This was the hardest part of the build by far. Synthetic events are easy;
trusted input is not. I burned weeks on edge cases — double-fired events,
focus behaving differently after programmatic clicks, drag sequences that
silently dropped — and there were moments I nearly went back to injection
because "mostly right" seemed acceptable. It isn't: the whole point of
replay is that it behaves like the user.

Decision 3: every failure ships with its evidence.

When a step fails, you get the screenshot of that exact moment, the failing
step, and the page state — not a red X and a stack trace. This feature
almost didn't make v1 (see below), and it turned out to be the thing users
mention first.

What got cut to actually ship

My first version had ambitions: visual diffing, parallel cloud runs, test
generators. All interesting. None finished. I cut everything that wasn't
"record once, replay reliably, show me what broke" — and shipped with
exactly that.

The first version another human could actually use was embarrassingly
small. It was also the first version people understood in under a minute.

Lesson learned the hard way: a tool with three features that all work beats
a tool with ten features that almost work. Especially in testing — trust is
the entire product.

How I use it in my own testing work

This is the part I care about most, because if my own tool doesn't survive
contact with my own projects, nothing else matters.

My weekly routine:

Record once, when the flow stabilizes. For a new feature, I record the happy path the moment it stops changing daily. One recording, not a maintenance project.
Replay after every meaningful change. Any change that touches the UI gets a replay before I call it done. What used to be an hour of manual click-throughs across the app is now a replay I kick off and read while it runs.
Read the evidence, fix once. When something goes red, the screenshot usually tells me whether it's a real bug or just a UI change before I even open the editor.

The screenshot has earned its place many times over. My favorite category
of catch: the page that "looks fine" but quietly shows a stale state — a
confirmation screen that renders before the backend actually committed, a
list that didn't refresh, a total that didn't recalculate. Those are
invisible to a pass/fail boolean and obvious in a screenshot.

The honest summary: I stopped doing the Sunday-evening manual click-through
of my own app. The suite catches what I used to catch by hand — and it
catches it before I've forgotten what I changed on Friday.

What I'd do differently

I would have shipped the failure-evidence feature in v0 instead of v1.1. It's the feature that makes people trust red results.
I underestimated how much time locators on dynamic lists would take. Elements inside virtualized lists are still the hardest case.
I would have shown the product to strangers much earlier. Every week I waited was a week of feedback I didn't get.

Where it still struggles

No tool should claim it handles everything, so here are our weak spots:
canvas-heavy visualizations, fully randomized UI layouts, and native mobile
aren't covered. If your app is one of those, my honest advice is that a
coded framework is still the better fit. (I also wrote up the technical
version of why recorded tests break in general — same story, more depth.)

That's the whole story. If you're using record-and-replay today, I'd love
to hear where it breaks for you — genuinely, because that feedback is my
roadmap.

CueCast is at icuecast.ai if you want to see
the thing itself. I'm the founder — questions welcome in the comments.

Why your recorded UI tests break after every redesign — and how to build replay that survives

Jim — Wed, 02 Sep 2026 10:13:17 +0000

If you've ever recorded a UI test, shipped one button change to production, and watched 40 tests explode in CI — you know exactly why "record and replay" has a bad reputation.

I've spent the past year building a browser testing tool, and I want to talk about the unglamorous engineering that decides whether a recorded test survives a redesign — or dies on first contact. Not the AI magic. The four problems underneath it.

1. A single locator is a single point of failure

Most recorders store exactly one locator per element — an XPath or a CSS chain — and freeze it at record time. That's the root of almost every "my tests broke" story:

XPath like //div[2]/main/section[3]/button[1] breaks when someone adds one <div> to the layout.
CSS chains like .v-btn.theme--dark > .v-btn__content break on any styling refactor.
Even data-testid — the community's favorite answer — isn't bulletproof. Third-party components don't have it, and a cleanup sprint that renames IDs silently kills dozens of tests.

The fix: don't store one answer, store a ranked list of candidates.

{
  "action": "click",
  "target": "Add to cart button",
  "candidates": [
    { "strategy": "test-id",   "value": "add-to-cart" },
    { "strategy": "role-text", "value": "button 'Add to cart'" },
    { "strategy": "text",      "value": "Add to cart" },
    { "strategy": "css",       "value": ".btn-primary.cart-action" },
    { "strategy": "xpath",     "value": "//button[contains(., 'Add to cart')]" }
  ]
}

At replay time, try the strongest match first and fall through on a miss. Then — and this matters more than people think — record which candidate matched. If your test passed via the XPath fallback, the page has changed in a way that deserves human review, even though the run is green.

Ranking rules that survived contact with real apps:

Semantic attributes first (data-testid, aria-label, name) — most stable, but often missing.
Role + accessible name — survives styling changes.
Text content — human-meaningful; great for buttons and links, useless for inputs, fragile under copy edits.
CSS chains and index-based XPath last — useful signals, never a primary answer.

No single strategy wins. The goal is that a test degrades gracefully instead of snapping.

2. Synthetic events are not real input

element.click() from JavaScript is not a click.

It invokes the event handlers, but it skips the browser's native input pipeline: no focus management, no :active state, no scroll-into-view, different behavior with native controls like <select>, date pickers, and file inputs. Tests pass on synthetic events and fail for real users — or the reverse.

The sturdier path is driving input at the browser level. The Chrome DevTools Protocol dispatches events through the same pipeline a real mouse and keyboard use:

await cdp.send('Input.dispatchMouseEvent', {
  type: 'mousePressed', x, y, button: 'left', clickCount: 1,
});
await cdp.send('Input.dispatchMouseEvent', {
  type: 'mouseReleased', x, y, button: 'left', clickCount: 1,
});

For typing, Input.insertText behaves much closer to a human than setting .value and firing an input event.

The trade-off: browser-level input is stricter — and that's the point. If a cookie banner covers your button, a CDP click fails, correctly, because a human couldn't click it either. Synthetic events would have "passed" while hiding a real bug. The price is that you must handle overlays deliberately instead of pretending they don't exist.

3. Don't fail at the first miss — and don't hide the miss

When the primary path can't locate an element, naive tools do one of two dumb things: fail instantly (flaky suite), or silently fall back (the test drifts away from what it was testing). Both destroy trust in the suite.

The distinction that matters is why the element wasn't found:

Not there yet — hydration, lazy loading, an animation still running. Wait and retry with a deadline.
There, but covered — modal, toast, cookie banner. This is a real finding; surface it, don't wait it out forever.
There, but different — the element moved or re-rendered. Try the next candidate, and log that you did.

So the failure ladder looks like:

CDP locate (primary candidates, ranked)
  → retry within deadline          # "not there yet"
  → DOM-level fallback             # CDP hit-test missed
  → next candidate in the list     # element changed
  → fail, with full evidence       # never silently

Every fallback gets logged and shown in the run report. A green run that used three fallbacks is not the same as a green run that didn't — and your team should see the difference.

4. The expensive part isn't running tests. It's triaging failures.

Do the math on flaky tests: one ambiguous failure costs a QA engineer 15–30 minutes of "is this a real bug or is it the test?" Twenty failures a day is a person-day of triage, most of it wasted on non-bugs.

So the most valuable feature of a testing tool isn't execution speed — it's the quality of evidence attached to a failure:

screenshot at the exact failing step
the step list up to the failure, with which locator each step matched
the candidate list the failed step tried
console errors and page context (URL, viewport, browser version)

We use AI to summarize the likely cause, but the recorded steps stay the source of truth. That's deliberate: an AI that silently "fixes" tests is just moving the drift somewhere you can't see it.

What record-and-replay is not for

Honest limits, because trust beats hype:

It won't replace unit tests or API tests. UI tests are for user-visible behavior.
It's weakest for canvas-heavy visualizations and deeply random data flows.
Best fit: critical-path regression — checkout, onboarding, admin workflows. The longer and more business-critical the flow, the more replay stability pays off.

That's the core of what I've learned building CueCast — a no-code tool built around these ideas: multi-candidate matching, browser-level input, and evidence-first failures. The techniques above work in Playwright or Selenium too; steal them either way.

How do you handle locator brittleness? data-testid everywhere? Playwright's getByRole? Visual AI matching? Curious what's actually holding up at your scale.