Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

A UI automation flow can break even when the user’s task still works: its selector may depend on a particular DOM arrangement, CSS class, or generated identifier that a redesign changes. In Playwright, the practical fix is to identify controls by their role and accessible name or their associated label when that reflects what the test is checking. Use a deliberately maintained test ID when the test needs an explicit automation contract. Then distinguish selector failures from timing problems; better locators help with the former, while waiting for observable page state helps with the latter.

Why does UI automation break after a redesign?

A selector is a description of how a script finds an element. If it describes incidental implementation details rather than the element’s purpose in the user task, a small interface change can invalidate it without changing what a person can do. For example, a script coupled to a deep DOM path may stop finding a button after the page’s containers are rearranged.

Playwright cautions that CSS and XPath selectors tied to the DOM can become non-resilient when that structure changes. Its documentation recommends locators that reflect how users and assistive technologies perceive the page, or an explicit testing contract where that better fits the test. Playwright’s locator guidance explains the options.

That does not make every break a selector problem. A target may have been removed or renamed, may exist but not yet be actionable, or the page may not have reached the state the test expects. A test may also be asserting incidental layout details rather than the intended behavior. Classify the failure before changing the locator.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Which Playwright locator should you use?

Choose based on what the test is meant to verify and who is responsible for keeping the locator contract intact. No locator type is universally stable: user-facing names can change when the interface changes, and test IDs require deliberate maintenance.

Locator strategy Good fit Stability consideration
Role plus accessible name Interactive behavior where the control’s user-facing purpose matters Reflects how people and assistive technology perceive the control. It can also provide early feedback about role or naming issues, but it is not a substitute for an accessibility audit. A changed name may be intentional and should prompt review of what the test is asserting.
Associated label Form controls with a meaningful label Expresses the relationship a user relies on to identify the field. Playwright documents label locators for labeled form fields.
Text Assertions about text or locating non-interactive content Useful when the text itself matters. A copy change may be either a meaningful behavior change or incidental wording churn, depending on the test.
Test ID A stable, explicit automation contract, especially when a user-facing role or name is not what the test needs to verify Playwright describes test IDs as the most resilient option, but they are not user-facing. Agree on who owns and preserves them.
CSS or XPath tied to implementation structure A specific structural detail is deliberately under test, or other locator strategies do not fit Long chains coupled to the DOM can break when the page structure changes. Prefer an intent-aligned locator or an explicit contract when the structure itself is not the requirement.

How to diagnose and repair a broken Playwright flow

  1. Classify what failed. Check whether the target disappeared or changed identity, is present but not actionable, has not appeared because the page is in an earlier state, or is found successfully while the assertion checks an incidental layout detail.
  2. Express the test’s intent in the locator. Replace deep structural selectors with a role and accessible name for an interactive control, or an associated label for a labeled form field. Use a test ID when a stable automation contract expresses the requirement more clearly than user-facing text or role.
  3. Scope repeated controls to meaningful context. If several records or regions contain similar buttons, first locate the relevant region or record, then locate the control within it. Make the target unique rather than relying on its position by accident. Playwright’s best-practices documentation demonstrates chaining and filtering locators.
  4. Synchronize on observable state. Playwright locators resolve the current DOM element when used, and actions auto-wait for actionability. Web-first assertions wait and retry for the expected condition. Prefer these observable conditions to fixed delays as a general synchronization strategy.
  5. Review the contract when the interface changes. If a control’s role, name, label, or test ID changed, decide whether the user-facing behavior changed or the test contract needs updating. Do not treat every failed locator as a reason to weaken the assertion.

Waiting does not repair a selector whose identifying contract has been removed or renamed. Conversely, rewriting a locator will not fix a page that has not reached the expected state. Keeping structural brittleness and synchronization separate makes the repair more targeted.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

How should teams reduce repeat breakage?

Make test impact part of review for changes to high-use UI flows. The authors of the 2025 ASE study “Who’s to Blame? Rethinking the Brittleness of Automated Web GUI Testing from a Pragmatic Perspective” report that 81.7% of the test cases repaired in their RQ1 failed again within about six months. That is a result for the study’s repaired cases, not an industry-wide failure rate.

The study authors recommend cross-functional review of UI changes for test impact before deployment. In practice, teams can make the review concrete by asking whether a change affects an asserted user behavior, a role or accessible name, a label, or an explicitly owned test ID. Give stable test attributes a maintenance owner; an attribute without an owner is not a dependable contract.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

These locator and synchronization recommendations are specific to Playwright’s documented behavior. The evidence cited here does not establish that every browser, desktop, or mobile automation framework behaves identically.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.