Common Selenium XPath Mistakes

Xpath is widely used in Selenium for web automation testing. We all have gone through challenges to find perfect XPath for that web element yet due to time constrain or ease to get and XPath via default browser finder or some chrome plugin makes leads to a very poor XPath selection for web element identification.

Well, nobody is perfect! Even if you have selected a poor XPath, we can always go back and refactor our web element’s XPath and find a better alternative for it. Below are the mistakes I have seen on various test frameworks. If we fix these mistakes it will lead to better clarity of the test scenario and less maintenance for the regression suite. 

1. Using Absolute XPath Instead of Relative

As we know there are two types of XPath in Selenium to choose. One is Absolute and another one is Relative. Below is an example of Absolute and Relative XPath.

Absolute Path : /html/body/div[3]/div/div/ul/li[3]/ul/li[14]/a

Relative Path : //ul[@class='home-list']//a[text()='Querying']

Absolute XPath should be avoided if possible. They tend to break the scenario under test regularly. Many times during new releases on production, the development team makes changes to HTML structure, absolute XPath will not work in such cases. For a new QA joined the team, it will be difficult to understand the XPath. They are not readable. After a few months, maintaining the scenarios will be challenging due to the flaky nature of it.

It’s better to use Relative XPath. They are easier to understand. There is some learning curve such as selector, axes, child-parent relation and functions like contains(), text(), etc. Using them makes the web element selector more maintainable. Relative provides a lot of better alternative solutions for a given web element.

2. Using * Instead of Proper Tags

Right way : //h4[@class='url']

Wrong way : //*[@class='url']

While using relative XPath, it’s suggested to be more specific on HTML tags. Many times we end up using * which is a wildcard to find any tag which matches the requirement of the current attribute/tag tree. This should be avoided. Its possible webpage HTML source page can be a size of half million and using * will take a long time to find out the given HTML Dom. Considering the above example, a webpage can have a class called ‘url’ having different tags such as div, span, h1, etc, using * will lead to the selection of the wrong web element.

It is better to use proper tags. To keep it simple, someone once said – “Take it as a compliment when someone complains that QA is very detailed !”

3. Not Using Custom Attributes

Our daily working with XPath, we use a lot of locators with attributes ranging from id, class, name, src, etc. But what if they suddenly disappear!

Hmmm… What is this disappear?? Let us say there is a project to revamp certain webpage which was previously written in Java and got migrated to react, there is a good chance that the developer might have removed the tag or id name or the entire HTML dom. This will lead to the failure of our test regression suite.

Developer tends to mess with them :). Its good practice to have tester’s custom attribute so that any new changes do not affect the test suite.

Example: data-div='cardname', data-e2e='zipper'

Summary

Lastly, please do not forget CSS is much better and faster than XPath. I would recommend using CSS but due to popularity & ease to find XPath I would suggest not making the above mistakes. Resolving the above mistakes will help you as well as your team member to better maintenance of the automation test suite, web element clarity, and reduce the flakiness of the test cases!

Thanks for reading. Happy Testing!