When it comes to changing IDs assigned to web elements on each page reload or session, such as button-1234 during one session and button-5678 at another, what are the strategies, tools, or best practices that can be utilized for locating and interacting with such elements during automation testing?
1 Like
I donāt have any great insights into how to deal with this, but I would like to take the opportunity to ask developers why the hell they design systems that do this? It only happens with perhaps 1% of the websites we test, so itās clearly avoidable.
I donāt do automation so it doesnāt affect me as much as people who do, but it still makes some things difficult. I look for something else thatās unique, such as a class name or element contents, but sometimes there just isnāt anything.
If all my work was for an organisation that did this, I would insist that they stop. Quality assurance is all about taking pre-emptive measures to assure quality, so removing impediments to testing is exactly what we should be doing. If the company didnāt listen to this advice, I would leave - there are plenty of other companies who donāt do that nonsense.
2 Likes
The only real solution is for the web elements to have some kind of stable identifiers (they donāt need to be id attributes specifically, they may be data-test-id or something else).
One way of achieving that is just doing it yourself. You need to be comfortable modifying developers code, be familiar with their tooling and have process support to propose such change.
Another way is talking with developers, and escalate it up the chain if needed. State the problem for what it is: you canāt create stable automation because software does not provide stable identifiers for elements.
Most frameworks that generate these random ids support turning that off for development environments. So your CI / QA / Stage build could have that disabled, giving you stable IDs to write automation against. Only production build would have random IDs. Of course that prevents you from running your automation against production, and requires testing environment to have a build that is somewhat different from production build.
As a supporting tactic, you can make the problem more visible for developers - send them notifications about automation failures, make your automation requirement in CI system. This will work only if your automation is already mature enough to cover something and if it has history of providing reliable results. This tactic has a room for escalation - you can start by just putting it out there and hoping that folks will jump to fix things when they see itās red. If they donāt take a hint, you can send a notification. Making automation pass a requirement for dev code change is atomic option.
If your organization does not support any kind of collaboration and this is truly your problem that you have to fix on your side, then see if you can match elements by their text content and then relative to other elements (e.g. āinput that is above button with text āsaveāā). This is brittle, but allows you to move forward. If your product is stable, you can get months or years of automation runs without changing these locators. And if your product changes views often, it begs the question if you really should be creating UI automation for it already.
1 Like
Maybe using something like https://testing-library.com/ ? Itās API is designed for writing browser automation using selectors more inline with how users use the app. Of course thatās no guarantee it will be easier 
Some apps feel actively hostile to automation.
1 Like
Hi @ramanan - can you do me (or us) a small favor? Please edit your thread (if possible) and shorten the title. There is enough internet left for the description and main fields 
Thank you.
And sorry, I have got no answer to your questionā¦
2 Likes
You could use a CSS selector like
[ID^="button-"]
This will match an ID that starts with button-. You can also use
[ID$="-button"]
Which will match an ID that ends with -button
ask developers why the hell they design systems that do this? It only happens with perhaps 1% of the websites we test, so itās clearly avoidable.
I would assume either lazy devs (who donāt do UI automation to know the pain points of QA), or UI libraries/frameworks being used that do this by default (whether configurable or not, itād be nice if the setting was not ādefaultā).
Are there any web elements where something of the element is static/constant across sessions and page loads? For example other HTML/element attributes besides the ID, text of/within the element?
And are there some elements with fixed IDs or all elements on the page have dynamic IDs?
In my past work on automation, from a reliability (minimal/no breakage of locators) implementation (with a trade-off on potential execution speed), I would use XPath and when possible CSS based locators. Such locator strategies give you more flexibility in identifying problematic elements by for example, anchoring onto more easily identifiable elements first then find the desired element of interest from there, relative to the more easily identifiable element. Relative in terms of being a sibling, descendent, or ancestor, etc. of the more easily identifiable element. Such strategy of course means you need expertise in advance XPath expressions and CSS selector expressions. In very complex cases, you need XPath since CSS syntax is rather limited in terms of navigating ancestors (or something like that) and restrictive in being able to locate by text of element.
In my prior work, Iāve found you at least have some easily identifiable elements on the page to anchor to. Worst case if no anchorable element attributes, usually the element text (seen on UI) is unique or static enough to anchor to (with XPath).
And the element text as part of locator strategy, while might be frowned upon by some, is also a good way to locate, because it matches the UI flow of how a user would describe certain elements based on the text. As a user using UI (not considering code underneath), you only know/see the text, you donāt see the underlying ID and other element attribute names. As such, this fits better with something like page object modeling or user acceptance testing, where youāre trying to describe on a higher level what youāre trying to do, and referring to element text is certainly more āreadableā for interpretation of the test/code.