TechAIDBlogToolsXPATH. With Great Power Comes Great Responsibility
By Mike Arias 04/11/2019 0

XPATH. With Great Power Comes Great Responsibility

Picture this. You’re writing a test script that needs to click a link to verify its functionality, but that button doesn’t have an ID or a Class that identifies it. How do you find it?

 

First, you have to decide if you’ll use a CSS Selector or if you’ll use XPath. For the sake of this article, we’ll go straight to XPath. If we look a bit deeper into the code we’ll see that this link is inside a <li> that has an ID, we can use this to our advantage.

 

To select this we could use something like:

//li[@id=’menu-item-14′]/a

In this case and on this site, this returns only 1 result which is what we want, but something looks fishy to my eye. What if “menu-item-14” is a dynamic ID and changes when we reload the page or changes if the creator of the site decides to add another item to that menu?

 

What will happen is that our code will break and we will have to fix it. That’s what’ll happen.

This means we need to find a more reliable way to find our element, for this we’ll need to look even deeper in the code. If we look a tiny bit deeper we’ll find that this <li> is inside a <ul> that has a unique ID, and that ID seems to be a static one that won’t change in the near future. This represents a much safer bet for our XPath to rely on.

 

If we use this as the start for our XPath, we will end with something like this:

//ul[@id=’top-menu’]/li/a

 

But wait, now we have another problem. This XPath will select all the links stored in this list, we need to narrow it down even more. For this we can follow 2 paths, we can either leave it as is and in the code handle the list of elements it returns, or we can be a bit more specific so the XPath only returns one element.

From previous experience, I’ve noticed that being specific and introducing the complexity in the XPath saves time on the execution of it and also makes your test script a bit cleaner in the end, since you won’t have to deal with index later on.

 

Our final XPath expression to select this link would look like:

//ul[@id=’top-menu’]/li/a[contains(text(), ‘Home’)]

 

So, question time. Why didn’t we ask for a link that contained that text from the beginning?

First, because that’s too generic of an expression. With an expression as simple as that we expose ourselves to find more things than what we’re actually looking for.

Second, an expression like that one is not efficient. That expression forces Selenium to go and look through the whole DOM of the site to find all the possible matches.

XPath is a really powerful tool, but it can easily make your code a lot harder to read, a lot slower and more prone to breaking because if anything changes in the path you’re using for your search, the XPath will break. And not only it will break, it won’t tell you which part of the XPath failed.

 

In conclusion, keep your XPath short, but not too short and specific enough to be able to resist slight changes in the DOM.

This article was written by Mike Arias
Senior Software Testing Engineer of TechAID.
Twitter: @theqaboy
Blog: qaboy.com/

GO BACK TO Tools

Leave a Reply

Your email address will not be published. Required fields are marked *

OTHER POSTS YOU MIGHT LIKE

HOW TO DESIGN GOOD MANUAL TESTS FOR ANY FEATURE?

By Mike Arias 05/07/2019 0

Picture this, you’re in a team working on a new product and you need to design a test plan for it. It’s the first time this product goes through any sort of QA process. Automation isn’t a top priority at the moment. The Product Owners…

WHY COMPLETE AUTOMATED COVERAGE IS ACTUALLY A BAD IDEA

By Mike Arias 04/01/2019 0

Wouldn’t it be nice to have 100% coverage of a system with automated tests? Imagine it. Not having to do any manual tests and every time something is updated, get a full report of the whole system. Everything would be perfect, no bugs would be…