How to eleminate usage of Xpath?

0
votes

I am new to protractor and while going through the official documentation, in the style guide section I found this.

NEVER use xpath Why?

-It's the slowest and most brittle locator strategy of all -Markup is very easily subject to change and therefore xpath locators require a lot of maintenance -xpath expressions are unreadable and very hard to debug

It makes a complete sense. However I am thinking of a scenario where i am accessing an element which is a repeated element(for eg. a row of a dynamically changing table). I won't have the particular id or name of the column to access that row, since it is created dynamically. However we can access the same using xpath expressions. One way I can think of is using the 'element.all(locator).get(index)' helper function, but since i am accessing the whole list of elements first, it looks like a slower process to me(say there could be hundreds of rows). The question is, since i want to eliminate the usage of XPATHs for all the reasons the official documentation of protractor states, do I have any alternatives in the above given scenario?

1
seleniumselenium-webdriverxpathprotractor
The sentence you're quoting is highly opinionated, and a lot depends on how well the HTML you are searching is structured. It certainly CAN be true that HTML pages contain 8 nested tables with no IDs and that their structure changes frequently; in that situation almost any strategy for screen-scraping is going to be fragile. - Michael Kay
That style guide says more about the limitations of the author than those of XPath. - kjhughes

1 Answers

3
votes

Here's what the docs state:

NEVER use xpath
Why?

  • It's the slowest and most brittle locator strategy of all
  • Markup is very easily subject to change and therefore xpath locators require a lot of maintenance
  • xpath expressions are unreadable and very hard to debug

As Michael Kay said in a comment, these statements are highly opinionated. I think most are easily proven false.

It's the slowest

A lot has changed since that statement was probably written. If you test XPath vs ID vs CSS selectors now in the top browsers, you won't find much, if any of a performance difference. I just did it the other day in Chrome and the three were practically indistinguishable in 1000 lookups.

most brittle

Any badly written locator can be brittle. XPaths CAN be written to be less brittle just as well as CSS selectors CAN be written brittle. I think XPaths probably tend to be more brittle because new automators use the copy XPath functionality in their favorite browser which usually creates bad/brittle locators. It's fine for when you are learning but you really need to learn how to write your own. You may have noticed that some browsers now have the copy CSS selector option... many times that also makes very brittle locators.

If you want to avoid brittle locators, you need to learn to handcraft your own locators. Doing this well takes a lot of reading and practice.

  1. If your XPath starts with /html, it's brittle. Don't do this.
  2. If it has more than 3-4 levels (e.g. //div/span/table/tr/td has 5 levels), then it's probably more brittle than it needs to be. The more you specify, the more rigid it is which means it's easier to break.
  3. If you do string matching (e.g. //div[@class='alert']), it's somewhat brittle. CSS selectors are much better here for specifying some classes on an element but not others.
  4. Using indices in locators can make for brittle locators, e.g. //table/tr[3]/td[2]. What if your data moves in the table? You are still looking at row 3, cell 2 and your data is now in row 4, cell 2. Your test will fail.

require a lot of maintenance

Kinda the same comment as above, a badly written CSS selector can require a lot of maintenance also. Write a good locator no matter what type you choose and you will minimize maintenance. Overly brittle locators brake often and require maintenance so don't write brittle locators. :)

xpath expressions are unreadable and very hard to debug

If you hate XPaths with a passion, tell everyone to avoid them, and never use them yourself, you'd probably think that they were unreadable and very hard to debug. :) They have a syntax that you have to learn to be able to read and debug them... just like CSS selectors or any programming language you use. Having said that, XPaths are more verbose and more complex than CSS selectors but with that extra complexity comes more power.

This is what I use based on my years with Selenium, in order of preference:

  1. ID
  2. CSS selector
    ...
  3. XPath

I only use XPath when the element doesn't have an ID and I can't use a CSS selector. There are basically two cases where that happens: 1. when I need to find an element based on contained text or 2. I need to do DOM traversal (e.g. the parent of some easily found element).

I follow the rules above and I rarely have to update locators unless there is a significant page change but YMMV.