Ruby/Selenium WebDriver XPath Pros and Cons

Question

I've been playing around with Selenium WebDriver in Ruby 1.8.7. Most items can be easily found with something brwsr.find_element(:link, 'Click Here') but not everything is accessible in this manner (at least not with the set of :link, :tag_name, etc. that I know of).

So after wasting hours and hours attempting to find an element with the above strategy I stumbled upon some example xpaths. I had never bothered to look into it before because I'd seen so many post (here on StackOverflow mostly) that were negative regarding xpath.

I found a Google Groups post on the Pros and Cons and the only Con really was that it was slower in IE. Since I'm doing all my work in a Linux environment (and therefore Firefox and Chrome) right now I don't care that it is slower in IE.

I've been working with xpath now for about 2 weeks and the development time for my test scripts is probably half what it was. And using xpath with find_element seems to always grab the right element where as I used to have some issues with the non-xpath method described above.

Given the number of 'I really want to avoid using xpath if I can' comments I've seen, I'm wondering what I'm missing. Or is xpath like regex and the people who understand it love and all those people who never bothered to learn it are somewhat mystified by it?

Answer 1

XPath can be inherently slow, but this doesn't make it a total no-go.

The problem generally tends to be performance and IE. All versions of IE suck at XPath. The good thing? You've already determined IE isn't a core part of your automated testing, therefore you can remove this a con.

As for performance, well, I tend to only notice a performance dip when you using complicated XPath queries. Basic ones tend be just as fast as searching by ID's etc, whilst it probably will be slower when you time it, I don't see much noticeable difference.

I tend to use XPath if needs be. If you've got a complicated HTML structure, I don't see why you wouldn't use XPath. It will get the test running. If it's slow, look at it after, but only after you get a nice green tick to say the test has passed.

Firefox and Chrome tend to be fine with XPath queries.

The other bad thing about XPath queries is that you can get into a mess if using very specific positions. For instance take this XPath to find the word 'test' in a complex table:

//div[1]/table[1]/tr[3]/td[1]/div[1]/a[text()='test'][1]

What if you add in an extra table row above the third one? The test will fail.

It can however be shortened to, which doesn't rely on the position of the underlying structure:

//table/descendant::a[text()='text']

Provided you know XPath queries back to front, and can optimise them, I don't see why not to use them.