My team is using Selenium WebDriver and the QA team is having the developers add IDs to almost everything. Is that normal or is Selenium flexible enough that tests can be written with the markup that is provided without having to go back and add IDs? For example, if you have a list of similar items you would usually just use the same class for each item and not put a unique ID on each item in the list.
7 Answers
It's not unusual. IDs tend to aid greatly in creating more stable UI tests, since class name changes or other refactoring is less likely to break tests. Also, dynamically populated lists tend to be high-maintenance in UI automation, and having predictable IDs can help with that. Using XPath is not only slow, as squeemish pointed out (and slowness itself can break tests if there are any timeouts, which leads those tests being fragile), but XPath also tends to be more vulnerable to UI changes, again increasing test maintenance.
Basically, your test engineers are probably finding that their test UI automation is fragile. This is a change from developers that can dramatically reduce test maintenance costs and, in turn, reduce the turn-around time on testing new builds. Fragility in UI tests is hard to manage, so other issues might also need to be resolved before you see the benefits of adding IDs.
answered Jun 27, 2013 at 20:51
We've found that developers have a tendency to change IDs willy-nilly. We can control it happening in our team, but when we merge with other teams' code, stuff breaks, xpaths change , and css breaks.
So now we've implemented our own css attribute - [data-automation] with its own ID. As long as this gets moved around with any elements, we can always find it and it's made our testing far more robust.
What works for one, may not work for another person tho ..
I try and use ID's as much as possible.
I don't like using link text as this prevents you from running test in other languages, and link text can also be changed due to settings, e.g. different customers may have different terminology.
ID's are less likely to change than the CSS, so I find that ID's on as many items as possible is all-ways best. This requires the developers to make sure that everything has ID's so you will need buy in from you whole team. (But it good practice for everything that can be to have ID's anyway.)
Some items however will not be ID-able, if there are many instances of that item on the page. For these I have found that the best solution is to have a custom tag and have HTML5 custom attributes that can be targeted by X-Path. This way they very unlikely to be affected if the page layout changes.
+1 to support an answer by Ethel Evans. It is reliability of UI automation in the long term that unique IDs can help with.
One other point to add is that sometimes you may have semantic CSS classes with elements instead of IDs. For example, on this site, question element is enclosed into
<div class="question">...</div>
while all the answers are within
<div class="answer">...</div>
Relying on semantic CSS class names may be a smart option as well if IDs are not available
Is adding IDs to everything standard practice when using Selenium?
From what I've observed in various companies over several years, this is a great approach, often championed by QA, but rarely done in practice.
In most companies that do web development I usually see markup decisions like this being made primarily by two groups - application and ux developers. They also have needs for ID's and classes for layout, ajax, styling. The most common practice I observe is that QA has to work using those identifiers placed there by the other two groups.
I have tried myself to push for unique ID's on all fields but developers and ux folks have their own needs to address first and they take priority. I've also tried the 'use data-attributes just for QA' but then the feedback is that we don't want that test markup in our production code being served to users. Most places are going to require you to work as a team on these decisions.
So, in my experience, the standard practice is that generally you have to work within the bounds given to you by developers and ux markup folks.
This means you need to learn a little bit more about good ways to identify fields and learning not to do things like
//tr/td/div/div/div/div/span
# XPath Too specific and thus too fragile, breaks when page layout changes
td.header
# CSS path Too general, applies to several elements.
I call it the goldilocks approach. Not too general, not too specific, short but unique is "just right".
answered Nov 12, 2016 at 14:17
-
hi, another question is placed here if you can answer, thanks sqa.stackexchange.com/questions/46093/… Nov 1, 2020 at 0:00
Selenium2/WebDriver can find elements with ID, Name, by CSS, by XPath, by Link Text, by partial Link Text, or by Tag Name. You need to specify what element you want to interact with by identifying it with a findElementBy*
Some elements I work with don't have IDs, so I use the XPath when interacting. Caveat...XPath is the slowest identifier to use.
answered Jun 27, 2013 at 17:48
The only benefit I can see from having the developers manually inject unique id's into all significant web elements is:
That it will make Selenium tests that you write much more human readable as opposed to using Css selectors.
Using IDs, you create an environment very friendly to using recording and playback ,such as with Selenium Builder because Ids are what Builder recordings "go for" by default. Therefore, builder won't fallback to creating whacky xpath or class name identifiers.
When it comes down to it, if you aren't looking for what I describe in the previous 2 items, then using css Selectors, etc. will work just fine for most people, especially if you use browser plugins, such as FirePath, to auto-create selectors for you when you need them.
qa-accept-button,qa-firstname, and the like. Developers may find this less obtrusive than an ID, and they're probably less likely to change them as long as they know why they're there.