Over the last few years, UI automation has changed a lot. Modern web apps are more dynamic than ever — heavy use of JavaScript frameworks, Shadow DOM components, frequent UI updates, and iframe-based integrations are now pretty common. While all this improves user experience, it also makes automation engineers deal with something that hasn’t really gone away: locator stability.
I’ve noticed that many flaky tests today aren’t caused by broken functionality — they fail simply because the locator that worked yesterday doesn’t hold up after a UI tweak or framework update.
Why Locators Feel Less Stable Today
Dynamic rendering everywhere
Frameworks like React, Angular, and Vue often regenerate parts of the DOM. IDs change, class names get refactored, or element hierarchy shifts slightly. Even small UI updates can impact selectors.
Shadow DOM adoption
Shadow DOM helps component isolation, which is great for developers. But from an automation perspective, it adds another layer to navigate and sometimes complicates locator strategies.
Iframes and embedded components
Many apps now include widgets, payment frames, analytics overlays, or micro-frontend components. These can introduce timing issues or context switching challenges during automation.
Faster release cycles
UI changes happen quickly. Continuous delivery means locator maintenance becomes ongoing rather than occasional.
What Teams Usually Do
From what I’ve seen across projects and conversations with other automation engineers, a few practices come up repeatedly:
Prefer stable attributes like data-testid or accessibility attributes
Avoid overly complex XPath chains tied to layout
Centralize selectors in page object models
Monitor flaky tests instead of just re-running them
Coordinate with developers on testability
These approaches definitely help, but they don’t completely eliminate locator instability.
A Slight Shift in Perspective
Traditionally we focus on:
“How do I find a locator that works right now?”
But increasingly I think the better question is:
“How likely is this locator to stay stable over time?”
That subtle shift changes how we think about automation design. It’s less about just locating an element and more about evaluating how resilient that locator will be as the UI evolves.
Curious About Others’ Experience
I’d genuinely be interested to hear how others are handling this:
Are locator issues becoming more frequent in your projects?
Do you rely on certain attributes or conventions?
How do you deal with Shadow DOM or iframe-heavy apps?
Any practices that noticeably reduced flaky selectors?
Final Thought
Automation reliability isn’t just about writing good tests — it’s also about choosing interaction points that survive UI change. As applications get more dynamic, locator strategy feels less like a technical detail and more like part of overall test architecture.
Would love to hear what’s working for you all.
Top comments (1)
I’d love to hear from you:
What strategies have you used to improve locator stability?
Do you track locator flakiness over time?
Any tools or custom approaches you’ve found useful?