Posts Tagged ‘browsers’

Sauce now supports Selenium 2.0 final, the new ChromeDriver and Firefox 5

July 13th, 2011 by Santiago Suarez Ordoñez

We’re pleased to announce we’ve been eagerly tracking the Selenium project as new releases come out and Selenium 2 becomes an even more awesome tool!

Selenium 2.0.0

We couldn’t be happier to hear that the 2.0 final release has landed. Everyone on the Selenium development team has done an incredible job moving this forward and making Selenium 2/Webdriver into what we believe is the best tool in the market for browser automation. As of last Friday, 2 hours after the release, we included Selenium 2.0 in our list of supported versions, allowing our users to start running tests on it by providing the right capability into their DesiredCapabilities object.

As of today, we’ve made 2.0.0 the default version for all users, as it’s proven to be the most stable and fast version.

Notice: We know some users were affected by this upgrade due to some newly unsupported commands in this release. We’ve since put in place new steps for making the upgrade process more apparent and painless for our users in the future.

Firefox 5

With the latest Selenium upgrade, support for new browsers was included as usual. And since it’s a fundamental part of our job to keep users up to date with cutting edge technology, we’ve included Firefox 5 support for both your Selenium 1 and 2 tests. Just go ahead and add Firefox version 5 to your list of browsers to test, and you should be good to go.

Scout users can also use Firefox 5 to manually test anytime. (Are you aware about Scout, our cool new tool? If not, you should!).

The new Chrome and Opera drivers


By now, you’ve hopefully seen the video of Simon Stewart presenting the new ChromeDriver during the closing keynote of  the 2011 Selenium Conference. If you were in attendance, you may recall the OH SHIT, THAT’S SO COOL! moment when attendees witnessed the new ChromeDriver running tests at blazing speeds as compared to the old version. But the importance of the new ChromeDriver and OperaDriver (which, as Simon mentioned, is just as fast and robust) is not only in their speed, but also in that they are no longer part of the Selenium codebase. They are now maintained by the right people: the browser vendors themselves. Right on, Opera and Google! We’re hoping the rest will follow along.

You can run tests using the new ChromeDriver by specifying it in your RemoteDriver’s DesiredCapabilities object. We’re currently working on getting support for the OperaDriver and will announce it as soon as it’s there. Here are the official release links in case you’re interested into getting these in your local setup too:

http://seleniumhq.wordpress.com/2011/02/09/operadriver_released/
http://seleniumhq.wordpress.com/2011/07/07/new-chromedriver/

For all of these releases, we owe a huge thank you to everyone on the Selenium development team. You guys are doing a great job, and your contributions to the project are constantly improving the quality of our service. For that (and a lot more), we humbly declare each of you the deserved owners of a Sauce t-shirt!

 

Happy testing!

Share

Why jQuery in Selenium CSS Locators Is The Way To Go

January 31st, 2011 by Santiago Suarez Ordoñez

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!

Share