Understanding XPath

-



Following my latest article "CssSelectors not only for styling" many people asked me about the difference between using CssSelector and XPath, and what are the benefits to using XPath as a locator. Sadly, I see many engineers struggling to identify an element by using other selectors, find themselves blindly copying a WebElement's XPath using the option provided by the browser. The deal is that the expression received is mostly highly flaky and ugly none the less.
In this article, I'm going to cover this topic and see if we can demystify XPath and make it more accessible.

What is XPath?

XPath stands for XML Path Language. It is basically a Quarry language that was originally made for selecting nodes from an XML document that was defined by the W3C. XPath can be used for XML schemes and also in many programming languages (Such as Java, Python, PHP, and even C).

How is it related to Test Automation?

XPath is one of the 8 locating methods (9 if you count relative locators added in Selenium 4 alpha). to identify elements in the application under test.
By using XPath we can query an element in a more flexible way, locating it by the full or relative path in the document object model and even use some of its internal libraries to compute a specific element by defining several conditions within the expression. XPath is a highly flexible and strong locating method. It allows us to locate elements by a static visible text, elements with no unique properties or even without any attributes at all.

How to use XPath to locate WebElements?

For this part, I'm going to use Chrome Dev Tools to demonstrate some usage examples.
The website I'm using is Google.com's main search page.

Understanding the syntax

Full path to a WebElement:


Let's say I want to query the first div on this webpage using its full path in the DOM which is:

/html/body/div

What does this expression mean?

Within the <html> tag, find the <body> tag, in the body tag, select the first <div> tag you find. And that will be my target element.

Relative path

In most cases using a relative path would be preferred. Why?
Let's look at a more complex example. Let's say that I want to identify the search text field.


This is the expression I need: 

/html/body/div/div[3]/form/div[2]/div[1]/div[1]/div/div[2]/input


In the <html> tag look for the <body> tag, find the first <div>, in which look for the third <div>, find the <form> tag in it, look for the third <div> in that tag... well, you get the point.

If even one of the "Stops" leading to my target in this expression "Breaks", the expression will no longer lead to the desired element.

Basically, I can identify the same element by using a shorter expression such as:


//input[4]

Which means, the third input tag in the DOM

or a stronger one:

//input[@type="text"]

Which means the first input tag with a type "text" you find. In our case it would be unique.

Locating by static visible text

Let's say that we want to locate this text:




Well, It has an ID but if it didn't I could choose to locate it via its static text with the following XPath syntax:

//div[text()='Google זמינה ב:  ']

But, what if only a part of the text is static?

Well, in that case, I could choose to find it with the "contains" keyword.

//div[contains(text(),'Google')]

 or:
 //div[starts-with(text(),'Google')]

What about an element's parent?

I can use the same expression to locate that element's parent. Fo example:

//div[@id='SIvCob']/parent::div

What if I want to find all elements on a page containing a particular text?

I can use Wildcards to find this element without specifying a particular tag

//*[contains(text(),'Google')]

Locating elements by providing multiple attributes

If needed, we can use multiple attribute selection in our XPath syntax. For example, I can locate the Search button by both name and type:

//input[@class='gNO89b'][@type='submit']

In conclusion:

Both CSS and XPath are highly powerful locating strategies. Depending on the use case you can benefit each of them as they provide you with great flexibility. XPath can navigate up the DOM while CSS cannot (As far as I know) and some say that at least in IE CSS is much faster.

By the way, there are websites such as cssify that help you convert your XPath expression to a CSS selector.






Comments

Post a Comment

Popular posts from this blog

Sharing is caring - Intro to Jenkins shared libraries

-
Image
  Whether you're just dipping your toes into the world of automation infrastructure, or already crafting your first jobs to automate your test execution, Jenkins is your new best friend.  In this blog post, we will talk a bit more about the practice of infrastructure as code, its relevance to test automation, and how you can avoid code duplications, align with industry best practices, and enable velocity, maintainability, and collaboration. So, whether you're a seasoned pro or just starting out, let's dive into the world of Jenkins Shared Libraries and see how they can make your life easier. Jenkins Shared Libraries play a crucial role in the realm of Infrastructure as Code (IaC).  So, what are they exactly? Think of Jenkins Shared Libraries as your secret stash of code snippets, neatly organized and ready to be plugged into your pipelines whenever needed. Let's explore the aspect of reusability within Jenkins Shared Libraries: Reusability is the cornerstone of efficien...
Read more

Test Automation in Docker: The Good, the Bad, and the WTF

-
Image
"The Illusion of Consistency in Dockerized Tes Automation" Hello folks, me again... knee-deep in another rabbit hole, banging my head against the Docker wall this time — and as always, writing about it once I crawl out the other side. You know the drill: you dockerize your test automation suite, pat yourself on the back, and declare: “Now it’ll run the same everywhere. We're finally consistent!” But are we really? Well, spoiler alert: not always . Let’s talk about this magical thing we all chase called consistency — and why Docker, as amazing as it is, doesn’t always give it to us out of the box. The Promise: One Image to Rule Them All The dream is simple: You wrap your entire test setup inside a Docker image — OS, tools, runtimes, configs, dependencies. You push that image to Docker Hub/Artifactory/Any other Binary Management system you might use, run it in CI, pull it locally, drop it on a colleague’s machine, run it on a server farm — and everything behaves the same . ...
Read more

Test Automation, Security, and other vegetables

-
Image
Automation, Security, and other vegetables What is commonly overlooked when focusing on Quality? In this blog post, I want to delve into an aspect commonly overlooked in the context of Test Automation, and that’s the Security aspect.  As test automation developers, we often overlook the basic fact that we are working on a software project. Just like any other software project, considering security in our test automation practices adds a vital layer of protection to our work environment and helps ensure that our work which was initially meant to save time and help quality efforts, will not provide an easy and accessible breach point to our application.  So, on this note, let’s dive into why security should be an integral part of our automation efforts and explore some strategies to ensure our project is as effective as it is secure.  Analyze the attack surface - Before we can effectively secure our test automation infrastructure, it's crucial to identify and analyze poten...
Read more