DEV Community

Aegis Runner
Aegis Runner

Posted on

Why Your UI Tests Break Every Sprint (And How to Fix It for Good)

You push a design update. The button still works. The user flow is unchanged. But your CI is red.

Sound familiar?

This is the daily reality for teams whose test suites are built on CSS selectors. Someone renames .btn-primary to .btn-primary-v2, restructures a form, or swaps a<div>for a <section> — and suddenly 60 tests fail. Not because anything is broken. Because the tests were looking for the wrong thing.

The Root Cause: Tests That Know Too Much

When you write a selector like this:
document.querySelector('#checkout > div:nth-child(3) > input.form-control')
you're not describing what the user experiences. You're describing how a developer happened to structure the DOM on a particular Tuesday.

That's a snapshot, not a contract.

The Fix: Test What the User Sees

Modern testing best practice flips the model: target elements by ARIA role and visible text, not by class names or DOM position.
// Fragile ❌
cy.get('.btn-primary-v2').click()

// Resilient ✅
cy.findByRole('button', { name: 'Submit Order' }).click()

The second selector survives any redesign. As long as the button still says "Submit Order" and has role="button", it will be found — regardless of what happened to the surrounding markup.

This approach, sometimes called selector resilience, is the difference between a test suite that helps you ship faster and one that slows you down.

The Hidden Benefit: Accessibility Auditing Built In

Here's the part most teams don't realise: if your test can't find an element by role or label, that's a real bug — not just a test failure.

A button without an accessible name is invisible to screen readers and to your test runner. Your test suite becomes a live accessibility audit, catching issues before they reach users.

Applying This at Scale

Manually refactoring hundreds of selectors is painful. The better approach is to generate tests that are resilient from the start — crawling your app and writing selectors against roles and labels automatically.

That's exactly what AegisRunner does. It crawls your application, discovers interactive states, and generates Playwright tests that use ARIA roles and visible text — so they don't break when your designers do their job.

If you're evaluating tools, this 2026 roundup of regression testing software is worth a read — it covers how different tools handle selector stability.

Quick Checklist

Before your next sprint, audit your selectors:

  • Replace index-based queries (nth-child) with role queries
  • Replace class-based selectors with label/text queries
  • Any element your test can't find by role → file an accessibility ticket
  • Add a linting rule to ban .querySelector in test files

Stop writing tests that know your implementation. Write tests that know your product.

If you want a tool that handles this automatically, AegisRunner's pricing starts free — no credit card required.

Have a selector horror story? Drop it in the comments.

Top comments (0)