{"slug": "why-your-recorded-ui-tests-break-after-every-redesign-and-how-to-build-replay", "title": "Why your recorded UI tests break after every redesign — and how to build replay that survives", "summary": "A developer detailed the engineering challenges behind building a resilient browser UI testing tool, explaining why recorded tests often break after redesigns and proposing solutions such as storing ranked locator candidates and using browser-level input via the Chrome DevTools Protocol. The developer emphasized graceful degradation and transparent failure logging to maintain test reliability.", "body_md": "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.\n\nI'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.\n\nMost 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:\n\n`//div[2]/main/section[3]/button[1]`\n\nbreaks when someone adds one `
`\n\nto the layout.`.v-btn.theme--dark > .v-btn__content`\n\nbreak on any styling refactor.`data-testid`\n\n— 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.\n\n```\n{\n \"action\": \"click\",\n \"target\": \"Add to cart button\",\n \"candidates\": [\n { \"strategy\": \"test-id\", \"value\": \"add-to-cart\" },\n { \"strategy\": \"role-text\", \"value\": \"button 'Add to cart'\" },\n { \"strategy\": \"text\", \"value\": \"Add to cart\" },\n { \"strategy\": \"css\", \"value\": \".btn-primary.cart-action\" },\n { \"strategy\": \"xpath\", \"value\": \"//button[contains(., 'Add to cart')]\" }\n ]\n}\n```\n\nAt 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.\n\nRanking rules that survived contact with real apps:\n\n`data-testid`\n\n, `aria-label`\n\n, `name`\n\n) — most stable, but often missing.No single strategy wins. The goal is that a test degrades gracefully instead of snapping.\n\n`element.click()`\n\nfrom JavaScript is not a click.\n\nIt invokes the event handlers, but it skips the browser's native input pipeline: no focus management, no `:active`\n\nstate, no scroll-into-view, different behavior with native controls like `