Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 15 down vote accepted

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.

share|improve this answer

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 ..

share|improve this answer

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.

share|improve this answer

+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

share|improve this answer

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.

share|improve this answer

The only benefit I can see from having the developers manually inject unique id's into all significant web elements is:

  1. That it will make Selenium tests that you write much more human readable as opposed to using Css selectors.

  2. 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.