Why you should use CSS selectors for your WebDriver tests

I didn’t used to be a fan of CSS selectors for automated web tests, but I changed my mind.

The reason I didn’t use to be a fan of CSS selectors is that historically they weren’t really encouraged by Watir, since the Watir API was designed to find elements by type and attribute, so the Watir API would look something like:

browser.div(:class => 'highlighted')

where the same CSS selector would look like:

div.highlighted

Since WebDriver doesn’t use the same element type/attribute API and just uses findElement with a By selector, CSS selectors make the most sense since they’re powerful and self-contained.

The the best thing about using CSS selectors, in my opinion, is the Chrome Dev Tools allows you to search the DOM using a CSS selector (and XPath selectors, but please don’t use XPath), using Command/Control & F:

chrome css selectors
Using CSS selectors to find elements in Chrome Dev Tools

So you can ‘test’ your CSS in a live browser window before deciding to use it in your WebDriver test.

The downside of using CSS selectors are they’re a bit less self explanatory than explicitly using by.className or by.id.

But CSS selectors are pretty powerful: especially pseudo selectors like nth-of-type and I’ve found the only thing you can’t really do in CSS is select by text value, which you probably shouldn’t be doing anyway as text values are more likely to change (since they’re copy often changed by your business) and can be localised in which case your tests won’t run across different cultures.

The most powerful usage of CSS selectors is where you add your own data attributes to elements in your application and use these to select elements: straightforward, efficient and less brittle than other approaches. For example:

a[data-e2e-value="free"]

How do you identify elements in your WebDriver automated tests?

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

5 thoughts on “Why you should use CSS selectors for your WebDriver tests”

  1. CSS was, as we measured it ~2009, 9 times faster in IE than XPATH. Don’t know how it is today but I assume it hasn’t changed since then.

    We do not use XPATH nor CSS. Our tool is using an own representation, most times idependently from the code. You can work with _in, _nearBy etc. in tables etc. Makes test code much more maintainable IMHO.

    Like

  2. “How do you identify elements in your WebDriver automated tests?”

    XPATH. NEVER CONVERT, NEVER SURRENDER. :)

    I’m curious if you have other reasons for not using XPath. It’s always been an either/or thing for me–they both have very similar functionality but look different. I use whatever is on-tap at the client.

    The text thing is actually one reason why I use XPath, and it’s what I go after when building locators. The places I’ve been have heavy focus on UX and so they don’t change text or look/feel as often, which means the text stays static for longer. Just my experience.

    Like

    1. I concur, and I plan to write a blog post sometime about it as well. Where I’ve worked, parts of the text in UI are fairly static by design (not your marketing, copy, promotional text that changes day to day), and if used correctly in locator specification, lead to template-able location strategy where you can find related elements of a group by varying the text identifier in the patterned locator value, and one that will work with/against dynamic ordering (e.g. the presentation of elements might be ordered differently from time to time, but the expected text will always be there if it is to be there as expected). So usability of text and XPath is probably a case-by-case basis for each web application/site being tested.

      Liked by 1 person

  3. Good post. I wrote a post a while back elaborating how one can test locators across browsers generically, even IE (pre-Edge): https://autumnator.wordpress.com/2013/05/02/testing-xpath-and-css-locators-firepath-style-across-browsers/.

    I would say there are some other things XPath can do that CSS selector’s can’t at the moment: traversing back up the DOM tree from a relative starting point, using siblings and parent/child/ancestor relations – CSS only lets you go down the tree; along with more fine tune control for nth element selection than nth-of-type or nth-child, which don’t work perfectly all cases when you want a specific nth element from the results – for XPath just specify the nth index; and the generic give me only specified index feature from multiple matches, e.g. “(xpathExpressionThatReturnsMultipleMatches)[n]” would give you the nth result from the matches.

    Until CSS can do all the above I mentioned, I’d still use XPath sometimes. The nth match from a set of matched results, and traversing up DOM tree is very useful at times. Some elements are easier to define meaningfully when keyed off a child element that you traverse back up to find a neighboring sibling or “cousin”.

    Like

Comments are closed.