What makes a good selenium locator?

Question

When automating UI tests with Selenium, it is often not absolutely clear what method and what locator to use to locate an element. Some locators are less reliable, less readable than others. And, usually, there are a lot of options to get to a desired element.

To be specific, here are some things we've enforced (with ESLint) in our UI test automation project (using Protractor for testing an AngularJS application):

• no bootstrap classes used inside CSS selectors (the idea is to use as less UI/layout-specific things to locate elements as possible)
• no internal angular classes inside CSS selectors - things like ng-scope or ng-binding are pure-technical and should not be used inside locators
• do not use "xpath" unless absolutely necessary (encouraged by this style guide)

The Question:

What other recommendations are there for locating elements in Selenium?

Answer 1

Good question, especially if people will read it and stop using XPath (I am not holding my breath).

• Selenium best practices mentions order of preference: id > name > css > xpath
• Mozilla explains why IDs
• Saucelabs explains why CSS locators are preferred over XPath
• slideshare compares locators (slide 23: CSS vs XPath)
• CSS vs XPath - with benchmark
• Simon Stewart with video

I read somewhere (cannot find the link) that another cause of flaky tests is locating elements by changeable attributes. Problem is, both browser and Selenium use internal cache to speed up access to attributes, so busting that cache might not be in sync and lead to flakiness.

• CSS vs XPath: benchmark says that with current browsers (page has no date, sadly) difference is minimal. But because pages are styled by CSS, we can expect CSS to be more stable than XPath. Has few links for follow-up considerations.

Exception where XPath is OK: parent element of the current one (if a parent has no ID or name).

My order of preference for locating elements is: By.ID > By.NAME > By.CSS_SELECTOR > By.LINK_TEXT > By.CLASS_NAME > By.TAG_NAME > By.XPATH

Answer 2

Choosing a good locator is very important to do carefully - it will define how reliable, readable, maintainable and durable your tests are going to be; how much dependent on the UI and design changes they are gonna be. Remember: maintaining end-to-end tests is, generally speaking, difficult and expensive (good read on the subject).

Here is a set of things to think about when choosing a locator:

• Scope. prefer "data-oriented" elements and attributes to "layout-oriented". In other words, try to not depend on page design choices. You don't, generally, want a seamless design change of a, say, container size to break your locator:

  • worse: .col-md-1.col-xs-6 input
  • better: .content input.email-input

• say "No" to XPaths. XPath is the slowest location technique; XPath expression are generally more difficult to maintain and debug (reference). And, when it comes to multi-valued attributes like class, you need to do extra concatenation to be able to reliably match a class out of multiple class values, which would increase complexity and reduce readability:

  • worse: //*[contains(@class, 'some-class')//input[@type='text']
  • better: .some-class input.email-input

• Technology. Try not to depend on the underlying technology of the UI implementation. For instance, in case of AngularJS, try not to use internal angular attributes or classes, like ng-scope or ng-binding

  • worse: .ng-scope.ng-binding
  • better: .email-input

• HTML structure. Try to depend on the HTML structure of the page as less as possible. The more elements you have in your path to the desired element, the higher is a chance that a UI change would suddenly break your locator:

  • worse: .content > table > tbody > tr:nth-child(2) > td.cell > input#email
  • better: .content input#email

• IDs are safe and fast. Searching elements by id comes down to browsers using document.getElementById() method which is optimized for speed. And, even though, nothing restricts duplicate id values on a page, they usually assumed and designed to be unique

  • worse: by.css(".content > .main-container > form.login input[type=password]")
  • better: by.id("password")

Some other related topics:

• Is adding IDs to everything standard practice when using Selenium?
• Which is the best and fastest way to find the element using webdriver? By.XPath or By.ID or anything else? And why?

Answer 3

I think most answers are pretty good, but I would like to focus a bit on the higher level of these questions and not the details.

What makes a good Selenium locator?

• Readability: Shorter is better, preferable with a clear unique name/id which describes this unique element on the page. Feel free to change the code like classes/names/id's to make the locator and the test-code very understandable and readable.
• Maintainability: The structure of the locator should be so uniquely good that it does not need to be updated if the location of the element in the page changes. Unless the functionality drastically changes you should be able to minimize the updating of locators and or tests.

In essence a locator should be written and read like the tester and the coder really cared about it. Clean Code matters also for page structure and tests.

What other recommendations are there for locating elements in Selenium?

• Centralize the locators in your test-code, keep it DRY. PageObjects may help.
• Work together with developers to create good locators! Change your process so this is possible. Good tip is to pair-program on the tests with developers if you are a separate QA person, you both could learn something.

Answer 4

For my money it is CSS Locators. Uses ID and/or class if there is one and uses position otherwise. Plus it is super easy to get Chrome to give you a CSS selector and test it in the console tab of DevTools via document.querySelector("yourCssSelectorHere") or doing a search on the Elements tab and pasting it in.

Most experienced Selenium users recommend CSS as their locating strategy of choice as it's considerably faster than XPath and can find the most complicated objects in an intrinsic HTML document. - SeleniumHQ.org

Answer 5

What makes a good selenium selector?

• uses css
• unique
• robust
• short
• descriptive

Given those quality attributes, in practice that translates into:

• Favor css over xpath for readability
  e.g. favor "form.new_user input.age" over "//form[@class='new_user']/input[@class='age']"
• Favor id's on the last element of a selector
  e.g. form.new_user input#last_name
• Consider adding selector scope elements purely for increased readability and stability
  e.g. the form.new_user in form.new_user input.last_name lets future forms be added
• Avoid using layout elements when possible
  e.g. avoid div section.top_header
• Avoid longer selectors with multiple elements
  e.g. avoid div.details div.users span.user form.new_user input.last_name
• Avoid non-english description words when possible
  e.g. avoid form.new_user56 input.lst_nm

Note that these are all good practice guidelines, not best practice rules.
They can be intentionally broken. A common example is when using frameworks that define values.

Answer 6

Explaining a bit more on how you can make your selector robust

Bad selector

If this is the selector you use

.content > table > tbody > tr:nth-child(2) > td.cell > input#email

And the input is moved out of table or even moved a cell, the selector breaks

Goodish selector

But if the selector was

.content input#email

Then it would work even if the input box was moved out of the table or adjusted within the table

Best selector

I'd usually use the most minimal selector though (best one)

input#email

This would be robust enough to handle any DOM changes unless there were

• the element would change its ID (existential change that has to be accommodated for in the tests)
• two input boxes for email with the same ID (non-case, IDs need to be unique)

Answer 7

Ideally, the most preferred locator to recognize a web-element in Selenium WebDriver is ID.

Reasons?

• It is short.
• It is fastest compared to other locators since in the background all it needs to do is pick the element matching the mentioned ID.
• It’s safest, as even if the location of this element changes or worse, even if it’s type changes, your test-script shall still be able to locate and identify the element.
• It’s robust as any changes in the surrounding elements usually don’t make any impact hence even if everything around the element changes yet the system shall be able to easily locate the element.

Then, why many Automation-QAs use other locators?

• In an ideal world, every single element should have an ID and every single element on a particular page should have a unique ID, but it may or may not be the case always.

• When Auto-generated IDs are used ID-locator shall not be able to detect. Worst case, duplicate IDs on a single page.

So what to do in this case? It totally depends upon the AUT, the patter developers followed to design the AUT, frequency of changes in UI-UX, the magnitude of changes in UI-UX and last but not the least, our individual preferences.

xpath though widely used if not used the strict way, can lead to issues if the location of your element changes, but till then it can uniquely identify the tiniest object on your web-page. Also, different browsers behave differently for xpath expressions.

CSS selectors and className locators fall in the same pit as xpath as whether a location may change of not, a web-application relies on its looks, and one of the key factors for its appearance is the UI. So, CSS selectors and className locators may happen to change more often than other locators.

tagName faces the issue of having multiple objects matching the given tag, hence it won’t be a preferred option, at least not my favourite.

So, apart from ID, what you choose as a selector totally depends on the factors I mentioned above and nowadays as the browsers are getting advanced I hope the differences of execution time these locators take to search in a complex developed web-application may be comparatively negligible, making the choice even harder.

Happy Testing!