Why jQuery in Selenium CSS Locators Is The Way To Go

Posted by Santiago Suarez Ordoñez in Selenium Resources

You may not have heard about this, but a while ago, Jason Huggins moved Selenium 1's CSS locator engine from CSSQuery to Sizzle, jQuery's CSS selector library. While this may not sound like a big deal to most users, it actually is, and in this blog post, I'll explain why and how to start using all the cool features that come with this change.

Update: For those of you using or willing to use Selenium 2/Webdriver, you may want to re-consider the special Sizzle pseudoclases like :contains or :nth that I'm talking about in this blog post. For technical reasons, injecting Sizzle in browsers driven by Selenium 2 is not as cheap as with Selenium 1, so the Devs have decided to rely on the browsers' implementation of CSS (standard CSS only) and fallback to Sizzle when needed (in case of old browsers which don't provide native css selecting for JavaScript). In Selenium 2 land, my advice, sadly, is to stick to the standard and avoid most of these shortcuts :,(

Why is Sizzle awesome?

Well, Sizzle is jQuery's selector engine, and that means A LOT. For those of you who don't know, jQuery is the javascript library used by almost 30 percent of all the websites. (As in, "30 percent of the whole effing Internet!"). Because of that, Sizzle gets an insane amount of usage, and therefore, testing. Sizzle's code is used by an average of 1 site for every 3 you visit. Its codebase has over a thousand followers on github and more than 80 forks as of today. That's a lot of eyes to catch bugs and improve performance. But it's not just a more robust and faster implementation of CSS that works on every browser. It has removed useless CSS selectors and added extra goodies that turn out to be pretty useful for people writing tests.

Sizzle's extra features you can use right now

As it says in its docs, Sizzle not only implements virtually all CSS 3 Selectors, but also extends them a little bit and adds its own, including some that are actually pretty useful for writing Selenium tests: :not The :not selector will help you filter out elements that are similar, but not exactly what you're looking for. Let's imagine the following situation:

<a href="#meh" class="confirmation_link hidden">Confirm</a>
... lots of html ...
<a href="#bleh" class="confirmation_link">Confirm</a>

As you can see here, there are two links in the page you're trying to test. Since they both have the same text, link=Confirm won't work because they're the same class and there is no id you could use to be more specific. In this kind of situation, the :not selector is our perfect weapon. It's just as simple as writing the following locator:

selenium.click("css=a.confirmation_link:not(.hidden)")

Thanks to Sizzle, complex filters can go inside :not. Here are some other examples:

selenium.click("css=.confirmation_link:not(div)")
selenium.click("css=.submit_button:not(#clear_button)")
selenium.click("css=input[type=button]:not(p#not_this_input > input)")

:contains Even though :contains was already present in cssQuery and the old Selenium, I thought it was worth mentioning. It can be used to filter elements depending on their inner text, so you can do something like:

selenium.click("css=div#myID > a:contains(Confirm Transaction)")

:eq/:nth This selector finds all the occurrences and then just filters the nth in the list. If are using the confusing :nth-of-type or :nth-child filters, this may be a great replacement.

selenium.click("css=table a:contains(Change password):nth(5)")

:header This selector will find you any header element. That is, h1, h2, h3, h4, h5 or h6. Pretty cool, huh? This way you can forget about which type of header your devs choose to use in the page. All you care to know is that it's going to be a header. Asserting a header that contains a specific text is the perfect situation for this:

assert selenium.is_element_present(":header:contains(Users Admin)")

Form helpers Additionally, Sizzle includes some form element shortcuts to save you from having to find out whether the element is a textarea element or an input. Even better, it saves you from writing ugly locators like input[type=checkbox].

  • :input: Finds all input elements (includes textareas, selects, and buttons).
  • :text:checkbox:file:password:submit:image:reset:button: Finds the input element with the specified input type (:button also finds button elements).

I think those are all important and you can check out the Sizzle's wiki for more info. We also released a CSS selectors quick reference if you'd like to have a cheat-sheet printed and close to your desk while you're writing your tests ;) Hope everyone is now writing jQuery Selenium selectors and found this post useful for saving some time and headaches. Of course, all of this is already available in our browsers in the cloud service, Sauce OnDemand, so go try it out for free!

Discuss: Why jQuery in Selenium CSS Locators Is The Way To Go
0 Comments

Free Trial

Get access to a free 14-day trial version, or contact Sales for more information.