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

5 Ways to Fail With Your Test Automation

-
Image
In theory, Test Automation tools are supposed to make things easier for testers, save time and provide us with an additional comfort blanket for our test coverage. And yet, so many organizations fail to implement a good, solid and scalable Test Automation infrastructure that could, in fact, save them time and return the invested resources. Some "Throw away" written Test-automation projects and others sustained in an on-going struggle with their goals to make a stable Automation suite.
Over the years I have seen many companies trying to implement their automation initiatives, I have seen written projects thrown away, frameworks switched and managers being fired because they failed to deliver what was promised or set as a goal.

There are many reasons for failure, and though automation makes perfect sense in the long run, we do need to realize that it is a lot more challenging as it seems.
Here are some of the things to be aware of before you jump ahead and start building your…
Read more

What's new in Test Automation? - Someone is pulling the strings once again

-
Image
Reading the headline of this article you are probably wondering what is the reason for the "Pulling the strings" analogy. Well, you will understand why in a minute.

So what is Playwright? Playwright is an Open SourceNode library for automating Chromium, WebKit, and Firefox by using a single API. It also supports Headless mode for all browsers on all platforms.
Playwright interacts with the browser via the native Debugging protocol (CDP) and according to the contributors was designed with the primary goal of boosting up test automation, eliminating flakiness, speeding up executions and allowing better browser operation. All things mentioned make Playwright an interesting new option for Test Automation.
Sound familiar?

If all of that sounds familiar to you, it is not a coincidence. Playwright was created by the same team that developed the notorious "Puppeteer" (Which is a very similar Node library that offers control over Chromium via the Dev Tools Protocol and is …
Read more

Automated Mindset

-
Image
A part of my fascinating role in Testim.io is arriving at our customer's headquarters and helping them achieve their automation goals. This type of Solution Architecture is truly challenging and interesting because there is no "One size fit all approach" and each company has its own unique challenges, agenda, mindset, and skillset.



There are many difficulties in implementing test automation, one of which is changing your mindset from manual testing to automation-oriented perception.
One of the first things I tell everyone I meet is "before a single line of code is written, stop! take a piece of paper and a pen and list down your goals. Plan as detailed as you can what it should be like".
I noticed by talking to testers, that it is very difficult for some of them to detach themselves from what they are used to perform manually and try to think about automated tests from a different point of view.
One of the biggest common mistakes is attempting to automate every…
Read more