Is element unique ID preferable to use as a Selenium locator than element text? [duplicate]

Question

There is a calculator app calculatoria.com. The task was to create test automation suite for the app. All calculator buttons have unique ids which were used to interact with them.

A button element looks like this

<div class="btnmar btn2" id="btn104" onclick="btnDown(this);">
<a href="#c" class="abtn2 zabtn" onclick="enter(8);blur(this)">8</a>
</div>

Where id="btnXXX" is always unique value for each element

Locator example

public By digit8Button = By.id("btn104");

When my code is reviewed I got a feedback that I should have used element text (digit) or CSS instead of element id. The argument was that ids can be easily changed but number text is more reliable. This doesn't correspond to many articles I've read while studying test automation about element unique id as the first option to create a good locator.

Answer 1

First off you should not choose a method based on the performance, but based on the maintenability. Executing UI tests is cheap compaired to maintening them.

Why choose a CSS selector over by id ?

• Easier to evaluate in the console via $(...) or with Ctrl + F in the inspector with Chrome.
• There's not really a difference it terms of performance since it will end-up calling the same engine.
• Some frameworks even convert By.id("btn104") to By.cssSelector("[id='btn104']") under the hood to ensure uniqueness.

Why choose by text over by id here ?

• There's no meaningful attribute which can be associated with the button. The id seems to be automatically generated and thus could change without notice. It would have been all right if the id was btn_8.
• Though be aware that selecting an element by text can become an issue if the application supports multiple languages.

Answer 2

Finding elements by ID is fastest option, because it eventually calls document.getElementById(), which is optimized by most browsers.

One can make the same argument about text being changed, same with CSS selectors, if you are working on a product that is under development; you can not guarantee that things won't change.

CSS selectors/Name are second fastest, then comes XPath. CSS selectors are awesome but not as flexible as XPath.

Answer 3

You are both correct in your own way.

As Moe Ghafari pointed out, finding elements by id is the fastest way to do so.

On the other hand, this is a calculator, it has static values on the buttons. This means that if, for whatever reason, they decide to change the layout of the calculator, your ids would have to be changed or your test would have to be corrected.

Answer 4

From my experience, id's can be wonderful, but application engineers tend to wipe them away when they are no longer useful to them, and are not interested in maintaining them for automation engineers.

Text, however, is a bit more stable and when it changes, there's usually a discussion about it.

If you use some encapsulation, you can set it up so that the text is passed as an argument and your code will be a lot cleaner.

Answer 5

It's all variable

Yes, using IDs are fastest, followed by CSS, then XPath (with using text as an offshoot).

However, IDs are only really great if used correctly. I've seen cases of:

• developer removes IDs for some reason.
• developer uses the same ID for multiple of the same thing, where they are only shown one at a time. So all the "Close" buttons for multiple modals all have the same ID. But since there is only ever one modal (and one Close button) shown at a time, they think it's okay to reuse.
• With the wave of Angular, Vue, React, and other frameworks, the devs don't assign an ID, but the framework assigns them randomly as needed. So it's "Button-104" this time, but refresh and it becomes "Button-017".
• developers change IDs to match some new sorting method (They inserted a new option to the middle of the navigation so all the navigation ID's were adjusted).

So in reality, IDs can be just as flaky as using CSS or XPath. Any change to the code can invalidate identification methods.

With the calculator, it may be more reasonable to use text as regardless of anything else, an 8 is an 8 is an 8. So even if they completely rewrite the layout and the markup, looking for a button with just the text "8" should almost always work.

NOW, that only works for the buttons themselves. You still would need to use some other method for reading the display. So while text would work for the buttons, it's not not an end-all/be-all answer.

So in the end, use the method that you deem will give the correct pointer with the least chance of needing to be updated next week.

Answer 6

In your concrete situation, I would:

• ask developers to add names, or
• locate by CSS class.

Locate all elements with same name/class (regardless of the generated id) and select desired one by checking other attributes (like text), which will likely remain constant even after future redesign.

This approach is much more robust than XPath, IMHO. Your programming language of choice (which you supposedly mastered) gives you more power and more flexibility than wasting time crafting unique Xpath locators (which will break after simple redesign).

Answer 7

You are right to use IDs , they are specifically chosen to be unique identifiers for this purpose. They can point to things that change without needing to be changed.

Web browsers use these IDs and ensure they are unique , so you get a smoke test for free. At least that is the theory, we've extended this paradigm so far beyond where it started.

For any non-trivial application you will need to stick to IDs to cope with the the rate of change and its a problem that a lot of frameworks don't see the clear value in using determinate ID's instead of ephemeral ones.

Ephemeral ID's just push the problem into somewhere else by requiring some kind of mapping layer between them and the real ones, i can guarantee someone at every org that uses these will spend an inordinate and painful amount of time navigating and debugging these abstractions. As a tester its important you can connect that time to the original decision to use the framework. If you are not careful that can end up happening on every test failure , keep tests and apps as simple possible.

There are other uses for IDs , if you want your app to be accessible to people who might not be able to see, might use different input methods or might want to use your website on unusual devices then these ID's become very important.

The worst argument for not using persistent ID's is security , you are only adding obscurity and hackers will know how to reverse your framework's obfuscation. Your backend should be secure enough that knowing these IDs will not compromise it.

Having a standard name for a thing across the whole of a project is an important ingredient for software quality , it reflects a common understanding which even if wrong is of more use than multiple competing definitions because you can fix it in a predictable amount of time.