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

Question

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.

Answer 1

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 css-selectors 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 love¹!

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.

---

¹_{Depending on what version of XPath you're used to.}

Answer 2

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 :

• Dave Haeffner who maintains Elemental Selenium carried out a test on a page with two HTML data tables, one table is written without helpful attributes (ID and Class), and the other with them.

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

• Css Vs. X Path
• Css Vs. X Path, Under a Microscope
• Css Vs. X Path, Under a Microscope (Part 2)