A test of relative locators, a selenium 4 new feature
This article has been written by Albert Ong, Lead QA at Veepee.
On the 15th and 16th February 2022, I attended the QA Global Summit’22, an online event mainly focused on Quality Assurance and testing activities. During these 2 days, speakers talked about interesting topics like test automation, coding good practices and presenting some testing tools.
One presentation specifically caught my attention: the one about Selenium 4, the latest version of Selenium, released in October 2021. Selenium is an automation testing tool that I use in my job as a QA engineer. The talk was made by Diego Molina, a technical lead at the Selenium project.
Selenium in a nutshell
Selenium is an open-source tool that automates web browsers and it is the leader in its category. It can be executed in multiple browsers and operating systems, supporting several programming languages like C#, Java, Python, NodeJS. Selenium offers a suite of software responding to different testing needs.
The QA engineers of Sales Creation tribe have built a test automation framework based on Selenium Webdriver, which controls the browser by communicating with it directly. It is a great tool to perform non-regression tests. However it requires programming knowledge.
During the QA Global Summit’22, Diego Molina presented the 3 new features of this version:
- Intercepting network requests
- Interacting with shadow dom
- Finding relative locators
I would like to do a little focus on relative locators, which is less complex to understand than the 2 other features and I could find a concrete case to test this new feature.
Relative locators
It would be easier to understand the concept of relative locators by an example. Let’s consider a web page containing several web components like below
If we select the component circled in red (the Boston component), Selenium 4 allows the user to find the component :
- Above
- Below
- On the left
- On the righ
- Near (Web element to be searched/located is at most 50 pixels away from the specified element)
How to locate web elements?
When writing a test automation script for a web application, we select the web elements defined in the DOM (Document Object Model). Basically, the DOM is an XML node tree defining the content of a web page.
Selenium offers several strategies to locate the web elements. The easiest one is by id. Ideally, the web elements have an id attribute, an unique identifier, which allows the tester to find the element quickly then interact with it in a test automation script.
Below, an example: the email field of Veepee authentication page has an id field
However, based on my experience and depending on how the web application is written, in some cases there is no id. In such a case, it is still possible to find a web element mainly by:
- CSS selector: find an element by its CSS style
- Xpath selector: a query language that helps to identify elements on a xml document
With CSS selector and Xpath, we can identify a web element by type of nodes (div, input, button, etc), by any attributes (class, style, role) and by ancestor/children nodes.
Below, another example in the Veepee authentication page, the Veepee logo does not have any id. So we can identify by the node type (img) and the alt attribute (logo)
The query by CSS: img[alt=’logo’]
The query by Xpath: //img[@alt=’logo’]
An important difference between CSS and XPath locators in Selenium is that CSS looks for elements going down the DOM, while XPath allows you to navigate both up and down. This means that using XPath, you can find child web elements and then easily capture their parent or other ancestor. However, depending on the XPath expression, it can be rather difficult to read. When deciding between XPath and CSS selectors, it is more about personal preference than it is about the pros and cons of the options themselves.
Whatever the method chosen, a good locator must be:
- Accurate: the locator should find the element you need.
- Unique: the locator should not find anything other than the target element or group of elements.
- Simple and clear: it should be clear which element the locator refers to without examining it in the code.
- Independent: the locator should be universal so that if there are changes to the interface, it remains relevant.
Study case: Brand Portal
To give more context:
- Firstly, in few words, Brand Portal is an application under Sales Creation scope, which allow Brands and internal stakeholders to check information about sales made by Veepee
- Secondly, the Brand Portal QA reported to me that he had some difficulties finding simple and consistent locators in some web pages.
Here the web page I want to test
The Logistic Management page contains one displayed table and we want to interact with the first row (framed in red) and save the data of each cell of the row.
When checking the DOM, the trick here is that there are 2 tables:
- One inside the displayed tab panel (in green in the image below)
- One inside an hidden tab panel (in orange in the image below)
Knowing that, here is a possible Xpath query to get the first row:
//*[@role=’tabpanel’ and not(@hidden)]//tbody//tr[1]
The query uses the Xpath function not() to invert the meaning of the argument. Xpath provides several functions like not(), contains() to filter the data retrieved and help you to find good locators. However, these powerful functions are often missed and they might be not intuitive enough for beginners in Xpath. So I would like to try another approach to find the first row, by relative locators.
When checking the DOM closely, we can see that the field to filter by operation code has a name attribute. So we can identify this field easily. And from it, we can select the row (the tr node) below.
Let’s code it in C#.
Below the statement to find the row below the operation text field using Xpath:
using relative locator:
Selenium 4 introduces the RelativeBy class to use relative locators. From it, I specify what node I am looking for, what node is the target: here a tr node (a row). From the RelativeBy class, we can call the method to localize the target element from the referential element (the operation text field).
Conclusion
Selenium 4 with the relative locators feature comes with a new strategy to find web elements. Relative locators become particularly interesting when the Xpath or CSS query are complicated to find and read: indeed, you need to:
- Locate the reference element
- Specify the target node of the web element you want to interact with
- Call the method giving the position of the target element.
As seen in the exemple above, the code to use relative locators is accurate, unique, simple and clear.
However, I would be cautious to use relative locators when the tested interface is not stable and the web elements inside move frequently. In such a case, I think relative locators are not relevant and there is a high chance that they do not aim for the expected element.
Annexes:
If you want to go a bit further about Selenium and CSS/Xpath locator, below are some useful links:
https://www.guru99.com/introduction-to-selenium.html
https://www.testim.io/blog/xpath-vs-css-selector-difference-choose/
