Why should I ever use CSS selectors as opposed to XPath for automated testing?

8
votes

Please help me understand why using CSS selectors are even an option for automated testing. I've been using the tool Ghost Inspector some in my workplace for creating lots of automated tests for our stuff. This tool gives you the option of using CSS selectors intead of XPath. Why?

XPath is SO much more durable than CSS. The CSS on any given UI is subject to change almost weekly on some projects/features. This make the tests extremely brittle and prone to being broken regularly.

Is it because most new test writers don't want to learn about anything XPath and wish to stick to the basics? CSS selectors look prettier than XPath syntax? Please convince me. thanks.

2
seleniumxpathautomationcss-selectors
Yes, Xpath is way more durable than CSS because it can invoke specific content contains functionality. On top of that, the argument that CSS is faster than Xpath is null and void with most processors at this point. Xpath is optimized for XML document handling. It can be a bit of a learning curve, but its versatility and power far outweighs its minor issues – pcwhite
@BoltClock I fervently believe your two comments would have made a great answer not only to this question but a clear guideline on xpath / css for the entire community of Selenium users. Should we re-open the question? – DebanjanB
@DebanjanB: I can, but I can't guarantee someone won't come along and deem this opinion-based (which it kinda is, admittedly) :) – BoltClock
... but honestly JeffC's answer to the duplicate sums up most of my thoughts anyway. – BoltClock
@BoltClock Reopened, I will add my take on this too. – DebanjanB

2 Answers

9
votes

JeffC's answer here does plenty to sum up the pros and cons of each locator strategy. But I'll address your points specifically.

First off, there is no need for anyone to convince you that selectors are better, because from a purely functional standpoint, they simply aren't (and I'm saying this as someone with a gold tag badge and almost 1000 answers to questions with that tag, so you know I'm not biased). If you're more comfortable with XPath, use it — in terms of features and what you can do, XPath is vastly superior, there really is no contest there. And, as you correctly state, performance is no longer an issue (if it ever was).

Selectors are there for quick and simple use cases and for users coming from HTML and CSS codebases, such as web developers, who want to get started with automated tests without having to learn another DSL. If you're responsible for the CSS of your own site you can also easily copy selectors from your stylesheet into your tests depending on what exactly you're testing.

If on the other hand you're coming from an XML/XSLT/XPath background, wonderful, you get to keep using the XPath you know and love1!

Yes, Xpath is way more durable than CSS because it can invoke specific content contains functionality.

Having a content contains feature doesn't make XPath more "durable" — it makes it more versatile. If you rely solely on an element's content and that content can potentially change or move around, your XPath becomes no less brittle than a selector that relies solely on an element's attributes or its position in the DOM tree.

You can do any of a number of things to make your XPath or selector more or less brittle, but that's an indicator of how versatile the DSL is, not how brittle it inherently is.

1Depending on what version of XPath you're used to.

7
votes

One of the most common conversation in the Selenium Community is which Locator Strategy is better among the two - Css or XPath with respect to performance. Supporters of CSS say that it is more readable and faster while those in favor of XPath says it's ability to transverse the HTML DOM (while CSS cannot). With such a divide based on different perspective it is hard to determine the best performing approach for you and your tests as a beginner. Here are some excerts from the industry experts :

ElementalSelenium_DataTables

Results with Finding Elements By ID and Class :

Browser                 | CSS           | XPath
----------------------------------------------------
Internet Explorer 8     | 23 seconds    | 22 seconds
Chrome 31               | 17 seconds    | 16 seconds
Firefox 26              | 22 seconds    | 22 seconds
Opera 12                | 17 seconds    | 20 seconds
Safari 5                | 18 seconds    | 18 seconds

Finding Elements By Traversing :

Browser                 | CSS           | XPath
----------------------------------------------------
Internet Explorer 8     | not supported | 29 seconds
Chrome 31               | 24 seconds    | 26 seconds
Firefox 26              | 27 seconds    | 27 seconds
Opera 12                | 25 seconds    | 25 seconds
Safari 5                | 23 seconds    | 22 seconds

The following were the takeaways :

  • For starters there is no dramatic difference in performance between XPath and CSS.
  • Traversing the DOM in older browsers like IE8 does not work with CSS but is fine with XPath. And XPath can walk up the DOM (e.g. from child to parent), whereas CSS can only traverse down the DOM (e.g. from parent to child). However not being able to traverse the DOM with CSS in older browsers isn't necessarily a bad thing as it is more of an indicator that your page has poor design and could benefit from some helpful markup.

  • An argument in favor of CSS is that they are more readable, brief, and concise while it is a subjective call.

    • Ben Burton mentions you should use CSS because that's how applications are built. This makes the tests easier to write, talk about, and have others help maintain.

    • Adam Goucher says to adopt a more hybrid approach -- focusing first on IDs, then CSS, and leveraging XPath only when you need it (e.g. walking up the DOM) and that XPath will always be more powerful for advanced locators.

Conclusion

So it appears to be a tough call to make. Especially now that we are aware with the knowledge that the choice is not as reliant on performance as it once was. The choice is not as permanent as choosing a programming language, and if you are using helpful abstraction (e.g. Page Objects) then leveraging a hybrid approach is simple to implement.

Trivia