Xpath: which is much more reliable source - Chrome or Firefox?

Question

On Google chrome, inspecting an Element and copying it's xPath gives me the following value

//*[@id='Body']/app-root/app-generic-product/section[2]/div/app-product-summary-list/app-product-summary[2]/div/div[4]/button[2]

I have tried getting the xPath of the same element in Firefox and it gives a different path:

/html/body/app-root/app-generic-product/section[2]/div/app-product-summary-list/app-product-summary[2]/div/div[4]/button[2]

My main test browser is in Chrome, and I tried the one provided by Firefox. It worked.

My Question is which is much more reliable, the one provided by Firefox or Chrome? In terms of testing with other Browsers (IE, Opera) and in terms of stability (if a developer makes very slight changes unrelated to the element.. will it break the xpath?)

Answer 1

Neither of those XPaths are ones you should be using when writing tests. They are so specific they become very brittle in tests, where even minor page changes will cause your tests to fail. You really need to be writing your own selectors for elements based from uniquely identifiable elements in the section of the page relevant for the specific test.

Answer 2

The first xpath is an example of a relative xpath.

Not the best example, but relative because it searches for the first element of any type from the root that has the ID of "body." The remainder of the xpath is the same.

The second xpath is absolute, which only means that it's hard-coded to start at the absolute root of the document and gets to the body tag that way.

More often than not, you'll want to use relative xpaths, but there are always exceptions. As to which is more reliable, I'd say neither, but a slight edge to absolute.

Answer 3

The first Xpath is relative xpath which locates the elements directly on a webpage. The second Xpath is absolute xpath which locates the element from the starting tag.

Always prefer to use relative Xpath to locate the web elements. You can use absolute Xpath also but when using this xpath if developers inserted a new tag in-between then your absolute xpath will fail.

Also generally Xpath will take relatively more time to locate web elements when compared to either locators like Id, class etc. In this if you prefer to use absolute Xpath means which will even slow down your script execution time.

Answer 4

Totally agree with @ThomasWalpole. Though first Xpath expression is relative, and the second one is absolute, they are both not a good case to use. Even the smallest change in page code, that may not be noticed by any other way, while working with your page under test, will (with a great probabibility) ruin both of these expressions. What kind of expression should be used, depends on what is the purpose of your testing. As I can see, you are targeting a button element. This gives me an idea, that you'll try to click this button with some kind of test automation tool, and check if the result. If this is the case, I would recommend you to implement the logic you are following when clicking a button as a human. You are examining the text/icon on the button, and maybe it's color or something. So try something like //button[text()='Click me!'].

If this will return more than one result, IMHO the best way to specify your query is to use css classes. Which ones will most likely not be changed in future is the subject to discuss with your developers team. In most cases a particular element will have several css classes, sometimes they will be even added\modified dynamically. Unfortunately, XPath knows nothing about html/css, it only works with the XML tree. To indicate, that your target element should have a specific class among the others, use the contains() function. The syntax here may look a bit uncomfortable to use at first, but it's a question of practice. Let's say, your button has a class myBTN. The xpath will look like //button[text()='Click me!' and contains(@class,'myBTN')] some things to notice - don't miss quotes or brackets. Every string value is always case-sensitive, if you need to check something ignoring the case, you must explicitly use a special function (forgot the name, easy to google if you need). Well that's the very basics, and also a couple of advice's from the following link

Here you can play with various constructions, checking the resuls immediately. And also, If I were you, I'd spend, let's say an hour, to read here - and try the examples given there, maybe with some variations of your choice.

Wish you best of luck!

Answer 5

You are correct that minor changes will break those locators which is why it is bad practice to use fully qualified xPaths as selectors, so neither should be acceptable. This is typically a symptom of writing the tests after the fact, rather than engaging in proper test driven develop. Engage with the developers and agree a strategy for well formed mark up which should include ID and Name attributes.

An important decision that needs to be made early in automated testing projects is the selector strategy to be used. There are several approaches depending on the specific objectives of the automated testing approach and team skills, but in general the choices from best to worse are :

1. ID attribute
2. Name attribute
3. xPath by element Type and the ID or Name
4. CSS selector by ID or Name
5. Label when unique on the page
6. (Partial) Text on Anchors & Buttons when unique on the page