A locator is a product contract
A useful locator describes what a user can perceive or what the product explicitly promises to automation.
Role, label, text, and deliberate test identifiers tend to survive visual rearrangement better than deep CSS paths.
A role and accessible name connect a button to the intended user experience. A position in a nested toolbar connects it to incidental markup.
This distinction lets designers move, group, and restyle controls without breaking unrelated behavior checks. A locator should fail when the meaningful user path fails.
Avoid encoding layout trivia
A test that depends on the third child of a wrapper is coupled to implementation details that the user does not see.
When the UI changes, that kind of locator fails without proving the behavior changed. That is noise, not protection.
Warning signs include selectors that describe grid positions, visual classes, generated component IDs, or long ancestry chains. These selectors become expensive as the interface changes.
The cost is not only maintenance. Flaky or brittle locators teach the team to distrust automation. Once the suite is seen as fragile, real failures have to fight through skepticism before they get attention.
Prefer intent before identifiers
Start with the user-facing contract: role, label, placeholder, visible text, and relationships that assistive technology also depends on. These locators improve test quality and often expose accessibility problems early.
Use explicit test identifiers when user-facing text is unstable, duplicated, translated, or insufficiently specific. They are especially useful for repeated rows, complex widgets, and workflows where the stable contract is internal to the product domain.
Use a deliberate identifier when the product cannot offer a stable accessible target for important behavior. Treat that identifier as an engineering contract.
Name identifiers after meaning, not implementation. Prefer data-testid="submit-order" over data-testid="blue-footer-button". The first describes behavior. The second describes a temporary design choice.
Give automation something stable
When accessible names are not enough, agree on small test contracts such as data attributes for critical controls.
Keep them meaningful and sparse. Test identifiers should support behavior coverage, not mirror every element on the page.
A good team agreement also defines who owns locator contracts. A design, component, or journey change can require a locator update. The team must also decide whether product behavior changed.
The payoff is a suite that fails for reasons people care about. Stable locators do not make automation perfect, but they remove an entire class of avoidable noise.
That gives the team more room to focus on deeper problems: test data, environment realism, assertions, and whether the automated journey still represents meaningful risk.