The Best Locator Strategy For Test Automation

There are so many questions when we start test automation of a brand new project. One of them is which locators to use for test automation. Many people have their own personal preferences, but did you know that there are some aspects which should be taken into consideration while making a choice? Some of the most common debates are related to performance of locators. Also an important question is how to handle changes in the HTML structure. The answer could be early participation of the QA in the solution design. Let’s discuss what is the best locator for test automation.

XPath

Why don’t we start with this one. XPath is an obvious choice for many people because of its flexibility. There are two types of XPath locators: absolute and relative.

Absolute XPath

Depending on the format you use. Absolute XPath is a direct way of finding elements. It starts from the root of the HTML document until the element you are looking for.

html/body/div/button[3]

Relative XPath

Relative XPath starts from a specific element and traverses through the HTML document until the requested element. With relative XPath you can move up or down the HTML tree to find parent or child element. You can use it to find elements by text or simply you can chain a few elements one after another to find the element. It can use the HTML attributes for simplified usage like in the second example below. Usage of logical operators is also supported.

//div/button[3] -- simple XPath

//form[@id='Registration']/button[3]  -- using attribute ID to find the element

//input[@id='name' or @name='name']   -- Logical OR in XPath

//a[text()='Sign In']   -- finding the element with 'a' tag by its text

It is quite powerful but it has some quite important limitations. With changes in the DOM, we might get an extra element in the hierarchy which is not part of the XPath. In this case the test will fail. According to some reports XPath is the slowest locator of all. I didn’t do any measuring personally and all the comparison results I found online were inconsistent to make a reasonable decision.

CSS Selectors

This type of locator is also very flexible and powerful. It uses HTML attributes, tags, IDs, classes, etc. for locating elements. It supports chaining the elements, logical operations and pseudo classes. There are two formats of writing the CSS selectors:

//both of the following examples are the same
div[class='button'] 
div.button

//example with IDs 
div[id='name']
div#name

//Chaining two elements
//div element has ID 'name' and somewhere within has class 'button'

div#name .button

// using :not pseudo class
// find div element with ID 'name' which doesn't have 'button' class
div#name:not(.button)

Avoid creating too long chains of CSS selectors, because they will be very difficult to maintain. If you don’t have anything unique to use it would be the best to ask the developers to add an attribute specifically for test automation.

CSS selectors are explained in large detail in Mozilla documentation. CSS selectors or XPath are the only choices for Cypress and Playwright because there are no specific methods for finding elements of specific type.

Selenium specific methods for locating elements

Selenium has advantage over Playwright and Cypress in a way that you can use their specific methods for finding the elements by class, ID, link text or tag name. This allows a bit simplified usage because you need to enter only the value of the attribute without the need to know much about CSS and HTML. It is a good option for beginners, although it can be handy sometimes even for more experienced engineers. In addition to these, Selenium 4 uses relative locators like Below, Above, Near, ToLeftOf, etc. Of course, Selenium also supports CSS selectors and XPath.

driver.findElement(By.Id('fname'));

driver.findElement(By.className("information"));

driver.FindElement(By.TagName("a"));

How to set a reliable locator strategy for test automation?

First, you need to make sure that your team is familiar with the strategy you choose. If you are not certain if they understand the concept of locators of your choice, you better organize trainings before the automated test creation starts. You want to reduce the risk of failing tests because of changes in HTML structure. Changes could be anything from renaming the classes to adding new elements in the hierarchy. As already mentioned in the introduction, QA engineer must be involved in the solution design. The best strategy to mitigate the changes is to introduce HTML attributes to be used just for test automation. Developers should add them for each of the components. The values for these must be unique to avoid conflicts and you can find them by either CSS selector or XPath. This is very useful for QA engineer because it wouldn’t be necessary to search for other unique attributes in HTML.

Conclusion

Selenium has certain recommendations for using locators. This excerpt from their tips is quite interesting:

In general, if HTML IDs are available, unique, and consistently predictable, they are the preferred method for locating an element on a page. They tend to work very quickly, and forego much processing that comes with complicated DOM traversals.
If unique IDs are unavailable, a well-written CSS selector is the preferred method of locating an element. XPath works as well as CSS selectors, but the syntax is complicated and frequently difficult to debug. Though XPath selectors are very flexible, they are typically not performance tested by browser vendors and tend to be quite slow.

I tend to agree with Selenium’s suggestion. Throughout my professional experience I did exactly as written above in combination with custom HTML attributes. Good strategy helped me with maintenance of the tests and quite often with debugging.