How do you make UI tests stable?

Direct answer

What a strong answer covers

How it works

Stable UI tests locate elements the way users perceive them, by role and accessible name, rather than by CSS paths or generated class names that change with every build. They control the data and the clock so the screen is the same on every run, and they wait for the condition the user would see, such as a button becoming enabled or a total updating, instead of fixed durations. Each test starts from its own state and does not depend on another test having run. Traces, screenshots, and network logs are captured on failure so a red run is diagnosable. Assertions that do not need the UI, such as business rules, are pushed down to API or unit tests where they are cheaper and more reliable.

Example

A checkout test uses getByRole('button', { name: 'Place order' }) and waits for the confirmation heading; it creates its own cart through the API before opening the page and freezes the clock so delivery-date logic is deterministic. When the design system renamed every CSS class, the test kept passing. Twenty pricing permutations that used to run through the browser became a parametrised API test, and the remaining UI suite dropped from 4 percent flaky to under 0.5 percent.

Common mistakes

• Locating by nth-child or auto-generated class names.
• Sleeping for a fixed time instead of waiting for a visible condition.
• Chaining tests so a failure in one cascades into the rest.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.