Posts Tagged ‘selenium’

Sauce Labs Eliminates Barrier to Automated Cross-Browser Testing with Sauce Builder

March 31st, 2011 by The Sauce Labs Team

New tool enables QA pros to build and run Selenium tests without Selenium expertise or infrastructure

SAN FRANCISCO, CA — (Mar. 31, 2011) – Sauce Labs, the web application testing company, today introduced Sauce Builder, a free testing tool that makes it easy for users to build Selenium tests without Selenium expertise and run them with the Sauce OnDemand service. Sauce Builder allows users to build automated Selenium tests simply by clicking through an application. By eliminating the complexity of hand-coding Selenium scripts, Sauce Builder accelerates the adoption of automated testing for QA and development teams that have been craving the development productivity Selenium offers. Sauce Builder is free and available for immediate download.

“Automated testing has historically been one of the most complicated, yet most valuable, technologies for companies that build software. Automated testing is doubly challenging because teams need to build and maintain a testing environment and on top of that, building tests can require significant technical skill,” said John Dunham, CEO of Sauce Labs. “We launched our Sauce OnDemand cloud service last year to eliminate the headache of maintaining a test infrastructure. Now with Builder, we’ve removed the next barrier to the adoption of automated testing and we’re very excited to see how this combination can help QA and development teams achieve their goals.”

With Sauce Builder, Sauce Labs continues to simplify and improve the cross-browser testing process for development and QA teams. Sauce Builder’s benefits include:

  • Build Selenium tests with zero programming – Simply click through your application and Sauce Builder writes a Selenium scripts that reflect your actions
  • Export results in the language of your choice – HTML, Java, Groovy, C#, Perl, PHP, Python and Ruby so your tests speak the same language as your application and dev team
  • Eliminate bugs faster – Use immediate video playback of your tests in action, and share them with your teammates
  • Remove test infrastructure headaches - Sauce Builder makes it a snap to either run tests locally in Firefox or in the cloud with access to all the browser / operating system combinations supported in the super scalable Sauce OnDemand service

With over four million downloads in just four years, the Selenium project is the world’s most popular functional testing framework for web applications. Designed to further expand Selenium adoption, Sauce Builder is the first web-based Selenium tool of its kind, including technology Sauce Labs acquired from Go Test It in 2010. After becoming more familiar with the technology post-acquisition, Sauce Labs elected to open source the code under the name “Se Builder” earlier this year because the technology held so much promise for the Selenium community.

Sauce Builder expands the capabilities of Se Builder by enabling users to directly access Sauce OnDemand, the cloud-based Selenium service, to run their tests. Sauce OnDemand is free to try for up to 200 testing minutes every month. Sauce Labs is also leading a collaborative effort with the Selenium community to deliver a new generalized plug-in architecture for Se Builder that among other things will support integrated plug-ins for testing services like Sauce OnDemand.

To learn more about how automated testing can accelerate your development velocity, please join Adam Christian,a Sauce Labs developer and project lead for Sauce Builder, on Tuesday, April 19th at 10AM Pacific for the webinar, “From zero to creating, storing and running automated tests in under 30 minutes”.

“Debugging takes up valuable time that developers could be using to focus on their applications,” said Sauce Labs’ Christian. “Now with Sauce Builder, developers can leverage this great development environment through our cloud testing infrastructure and not worry about dealing with building or maintaining their own costly testing infrastructure.”
About Sauce Labs
Sauce Labs, web application testing company, provides Sauce OnDemand, a cloud based service that allows users to run automated cross-browser functional tests faster and eliminating the need to maintain their own test infrastructure. To date, over four million Sauce OnDemand tests have been run in the Sauce cloud. The lead investor of Sauce Labs is the Contrarian Group, Peter Ueberroth’s investment management firm. Sauce Labs is headquartered in San Francisco, California. For more information, visit http://saucelabs.com.

Media Contact
Chantal Yang
LEWIS Pulse for Sauce Labs
sauce@lewispulse.com
415-875-7494

 

Share

Testing Your Mobile Apps with Selenium 2 and Frank

March 30th, 2011 by Ashley Wilson

In case you missed our last SF Selenium Meetup, check out video below of the two great presentations on mobile testing. Pete Hodgsen, a software consultant with Thoughtworks, discussed how to use Frank, a new testing framework he’s involved in developing, for automated acceptance testing of native iOS apps. Jason Huggins, creator of Selenium and co-founder of Sauce Labs, followed this by demoing how to test Android and iPhone applications using Selenium 2.

Many thanks to our friends at CoTweet for co-hosting and making this last meetup such a success! If you think your company might be interested in hosting a future meetup, please get in touch. Our next meetup will be in early May at Mozilla (we’re skipping April because of the Selenium Conference happening next week). Stay tuned for more details!

Share
Posted in General, Meetups, Videos

The Selenium ‘click’ Command

March 22nd, 2011 by The Sauce Labs Team

Introduction

The golden rule of web application testing states that “You can find a number of bugs by simply clicking randomly on various places.” This is especially true for User Interface bugs. If you are using Selenium or Selenium-RC for automating your application’s User Interface tests, it is important to know how the “Selenium.click()” command works in order to simulate user clicks.

While it’s one of the lesser-advertised features of Selenium, it’s a blessing in disguise for testing application behavior for various UI elements without needing any manual intervention. For instance, we recently tested a JSP form with a few dozen dropdown lists (single and multi-select), checkboxes, and a plethora of radio buttons. Clicking each UI control manually was a pain in the hand. In contrast, simulating these clicks using Selenium not only saved crucial manual testing effort, it helped uncover a number of important bugs in the application as well.

How to use the Click command?

To put it in simple words, the click command emulates a click operation for a link, button, checkbox or radio button. It takes a locator (an identifier for which HTML element the command refers to) as an argument.

Example – The following command invocation simulates a click on a button element named myButton

selenium.click("myButton");

Browser Support

The Selenium click command works in the following browsers

Browser Versions
Firefox 3, 3.5, 4
Internet Explorer 6, 7, 8, 9
Safari 3, 4, 5
Opera 9, 10, 11
Google Chrome current

Language Support

The Selenium click command works in the following languages

Language/ Tool Command Name
C# 
selenium.Click
Java 
selenium.click
PHP 
$this->selenium->click
Python 
self.selenium.click
Perl 
$sel_click_ok
Ruby 
@selenium.click
Selenium IDE 
selenium.click

Challenges and Workarounds

The Selenium click command offers basic locator click functionality. Though it has several limitations, these can be overcome using the following workarounds.

  • How to click on specific coordinates?

Click command is only capable of clicking on a specific element locator. It can’t click on an element using the coordinates of the mouse event relative to the element locator. Example

selenium.clickAt("myButton", "50,50");

Moreover, it can be used to have the same effect as click command by specifying the coordinates as “0,0”. This is especially true when using JavaScript frameworks such as extJS and GWT where click command doesn’t work very well because it does not trigger the mouseUp event.

  • Does issuing the click command fire the onblur event?

No, it doesn’t. That’s the reason why you should use the fireEvent command in such cases. Example

selenium.FireEvent("Cancel", "click")

Sample HTML

Let’s consider the following example as a reference point to understand how the Selenium click command works.

<!DOCTYPE HTML>
<html>
    <head>
        <script type="text/javascript">
            function show_msg(){
                alert("Selenium Rocks!");
            }
        </script>
    </head>

    <body>
        <input type="button" id="myButton" onclick="show_msg()" value="Show Message" />
    </body>
</html>

Example Test Cases

Let’s consider the following test cases to understand how the Selenium click command works in various languages. In each of the code snippets provided below, we first open the application root, set the value “selenium rc” into the field named ‘q’, invoke the click command on myButton and then wait for 30 seconds for the page to load.

  1. Python
self.selenium.open("/")
self.selenium.click("myButton")
self.selenium.wait_for_page_to_load("30000")
  1. PHP
$this->selenium->open("/");
$this->selenium->click("myButton");
$this->selenium->waitForPageToLoad(30000);
  1. Ruby
@selenium.open "/"
@selenium.click "myButton"
@selenium.wait_for_page_to_load “30000”
  1. Java
selenium.open("/");
selenium.click("myButton");
selenium.waitForPageToLoad("30000");

  1. Selenium IDE HTML Suite Test
open /
click myButton
waitForPageToLoad 30000

Using Selectors with Click Command

The Click command can also be used in conjunction with the following selectors.

1. css=

The CSS selector is often used with Selenium click command to uniquely identify an object or element on a web page. For example

selenium.click("css=input[name=myButton]”)

The CSS locator is especially handy as an alternative to XPath locator which works painfully slow with IE.

2. name=

As the name itself suggests, the name selector is used to click the first element with the specified @name attribute. For example

selenium.click("name=myButton”)

3. id=

This allows click on an element with the specified @id attribute. For example

selenium.click("id=myButton”)

4. link=

This allows clicking on a link element which contains text matching the specified pattern. For example

selenium.click("link=myLink”)

5. xpath=

This allows clicking on an element using an XPath expression. For example

selenium.click("xpath=//input[@name=myButton' and @type='submit']")

We hope that you find this write-up informational and it helps shorten your Selenium learning curve.

Happy Testing!

Share

Announcing Support for Internet Explorer 9 and Firefox 4 in Sauce OnDemand

March 15th, 2011 by Santiago Suarez Ordoñez

Here at Sauce Labs, we’re committed to keeping Sauce OnDemand, our browsers-in-the-cloud service, up to date with every new browser release. That’s why we’re especially thrilled to bring you fully supported IE9 and Firefox 4.0 browsers in the cloud, ready now for everyone – even free accounts – to use.  Also, at the end, for the do-it-yourself Selenium users, we share some of our “secret sauce” for installing these browsers.

Watch them running

Firefox 4 in the coud (see the full job in OnDemand):

Internet Explorer 9 (full job in OnDemand):

Use them yourself!

All you have to do is to create an account if you don’t have one yet, then start your Selenium RC tests using the right browser version and OS in the special Sauce browser string.
Of course you can find the browser string to use in our supported browsers page, but to save you some time, these are the ones you’re looking for:

"os": "Windows 2008", "browser": "firefox", "browser-version": "4"
"os": "Windows 2008", "browser": "iexplore", "browser-version": "9"
Notice: IE9 only runs in Windows Vista or later, so we’ve created new Windows 2008* VMs just for this! This means, though, that it’s important to provide “Windows 2008″ as the OS version requested.

This is how we did it

We founded Sauce Labs in part because we believe most people working on software testing have higher value uses for their time than maintaining test infrastructure.  And also because we believe in the power of open source to make a positive contribution.  So for those Selenium users for whom using Sauce OnDemand is not yet an option, we want to give back to the community and share the following How To section so those users can more easily install both FF4 and IE9 in their own test lab.

The following outlines how to configure and install both browsers.

Setting up Firefox 4

firefox 4 logo
To make Firefox 4 ready for Selenium testing we must ensure it is visible to Selenium.  Here’s how. Choose the Custom option during installation and make sure firefox is installed in C:\Program Files\Mozilla Firefox.

Selenium will find Firefox once it is installed in that location. No further configuration needs to be done, since Selenium takes care of the rest using its own custom profile.

Setting up Internet Explorer 9

ie9 logo

Internet Explorer 9 requires more work to set up. We’ve seen users having issues bringing up the browser as well as performing basic driving actions.

With the accumulated lessons learned from 4 million Selenium tests and counting, our VMs contain a series of registry edits that make Internet Explorer work like a charm with Selenium, as well as run tests faster.

We have made Sauce registry edits available in the their own public gist.  Please only follow these instructions if you are complete comfortable with the process and terms.  To run them just download the files and run the following from the command line:

From the administrator account in your test machine, enter:

regedit /s admin_regedits.reg

As the user running Selenium (may be the administrator user too):

regedit /s user_regedits.reg

Warning: The configurations resulting from these registry edits make should only be used to run in dedicated testing servers. Using them on a machine intended for everyday usage, such as checking email and working, will be a security risk.

If you run into problems with this setup, feel free to ask questions in our Sauce OnDemand forums or our Selenium forums (depending on whether you’re using our cloud service or setting this up locally). We do our best to answer any questions that come through. If you’re looking for faster and personalized responses, we do offer paid Selenium support packages, which give you access to our Selenium experts via phone, email, and chat.

* Windows Server 2008 RC1 is Microsoft’s server OS most closely related to Windows Vista (they have the same NT kernel version number).

Share

Se Builder: Released into the Wild

March 8th, 2011 by admc

Over the last few months, an effort has been underway here at Sauce Labs to take a bunch of interesting test-building technologies, clean them up a bit, and merge them into one project. The result is Se Builder, a new Firefox extension environment for building Selenium tests that combines the best elements of Windmill IDE and Selenium IDE with parts of a proprietary technology Sauce Labs acquired a while back.

You may be wondering, “What’s the difference between Builder and the already existing Selenium IDE?” While there are many, the big ones are that the user interface in Builder is comprised of standard HTML, CSS, and Javascript. Our hope is that if you use web applications regularly, you will be able to comfortably use Builder. Secondly, we realized that exporting tests in order to run them with your Selenium RC server was unnecessary – so we took that step out.

We have big plans for Builder going forward. One of the visions we have is to continue improving the UI so that it makes suggestions to users for constructing better tests, changing it from a simple test generation environment to a teaching tool as well.

We have fully open sourced the project on Google Code and set up a Google Group mailing list to help people get their questions answered. We also want to make Se Builder as intuitive as possible, so we have been conducting formal usability testing and actively implementing our findings. The next big step for Builder, which is happening completely via standard OSS process, is a plugin architecture – allowing anyone interested in developing for Builder to expose and integrate custom functionality.

Further out, we would love to see forks of the project for each of the different browser plugin platforms. Since there are a couple bits of the project that are Firefox trusted Javascript specific, we would need to abstract that out for each of the platforms. However, the rest of the project is using standard web technologies and jQuery, so we hope porting that part of the project will be a straight forward process.

We are excited for as much community involvement as we can get. If you give Se Builder a try, we would love to hear what you have to say!

Project Links:

Open Source Project Homepage: Builder Google Code Project
Mailing List: Builder Google Group Mailing List
Download: Builder Google Code Download Link

Share
Posted in General

#SFSE Video: Selenium Problem Solving Sessions

March 2nd, 2011 by Ashley Wilson

A new year of San Francisco Selenium Meetups got off to a great start with our February meetup, hosted by our friends at OPOWER. Attendees were treated to four different presentations by:

  • Eric Allen, a developer at Sauce Labs, who spoke about the different ways you can (and should) use Selenium’s Proxy Server
  • Dan Fabulich, Senior QA Engineer at Redfin, who shared a technique for using Selenium to automatically test files on a disk
  • Lalitha Padubidri, Lead QA Engineer at Riverbed, who gave attendees a glimpse into the Python-based Selenium infrastructure that Riverbed has built out, and
  • Alois Reitbauer, Technology Strategist at dynaTrace Software, who demonstrated how to integrate your Selenium tests with dynaTrace Ajax, a free tool that analyzes performance and functional problems.

In case you missed the event, check out the video below for the full presentations. And if you haven’t joined the SF Selenium Meetup group, well, get to it :) We meet once a month at different venues around the city to mingle, drink beer, eat pizza, and hear various presentations on Selenium. It’s not only a grand ol’ time, but it’s free. Next meetup is March 16 at Co-tweet. Details to come soon.

Share
Posted in General, Meetups, Videos

Hey, Selenium. Hurry The Hell Up.

February 11th, 2011 by The Sauce Labs Team

I love automated browser tests, but I *really* love fast builds. The faster the better. So when a build that I’m waiting for starts taking over 5-10 minutes, all I can think to myself is… “Hurry the hell up!” And we all go through it, even here at Sauce. So here are a few things we’ve found to really help speed up Selenium testing:

1.) Paralellism

The more tests you can run in parallel, the faster your build can finish. So when writing your tests, always ask yourself, “Can I run this test by itself and have it pass?” If you think to yourself, “No… another test has to run *before* for this one to pass,” then stop. Put the shovel down, and start climbing your way out of that hole. Tests that rely on previous tests cause random, weird bugs to pop up, are hard to run when you want to reproduce those bugs, and are just slow. So keep your tests independent. It’s how they were meant to be anyway.

When none of your tests are inter-dependent, that means they can all be run in parallel, and in theory, your entire build should only take as long as your single longest test (in practice, it’s a bit longer, but not too much). Which brings us to the next point…

2.) Short Tests

Write your tests to only test a single tiny bit of functionality. Keep the number of steps in your tests under 20. All the parallelism in the world won’t save you from long-running tests, because a single test can’t be parallelized. The best written tests we’ve seen generally run in under 10 seconds. Yeah, I know. That’s short. If you’re wondering how that’s possible, check out step #4 (but be patient, we still have to get through step #3. Don’t rush me.)

A pleasant side-effect of this is that when a build fails, you’ll be able to narrow it down to a very specific area point and fix it all the faster.

3.) Sauce Connect 2, BOOST MODE!

Take a breath. A deep one. Then repeat “Sauce Connect 2, BOOST MODE!” to yourself, slowly, with some real emphasis on the “BOOST MODE”. Nice huh? Even if that’s all it were, it would be worth it, but there’s more. A whole lot more.

Sauce Connect 1 was a python-based tool that could easily and securely connect a staging server behind a firewall to the Sauce OnDemand browser cloud. Raved about by developers, sysadmins, and network admins alike, it was a cornerstone in enabling (very) security-minded orgs to bask in the glory of the Sauce Cloud. Even so, we knew it could go further, so why not push it?

Sauce Connect 2 is java-based (we lovingly call it “Enterprise Edition” internally), and in addition to some handy things like not having to specify each domain by hand anymore, it comes with BOOST MODE. Not ‘boost mode’, BOOST MODE. It looks faster that way.

When launching Sauce Connect 2 with the -b flag, it activates some magic under the hood and causes reduced traffic to your server, and speeds up resource-intensive tests considerably. And though it works for everyone, for our friends in distant lands in particular, you’re really going to love it.

Best part is, it’s just a -b flag. Couldn’t be simpler.

(Note: For the time being, this only works on Firefox and IE, though we have support coming for Safari and Chrome. Also, this isn’t “released” yet, so it’s my gift to you, our loyal reader. Let’s just keep it a secret between us, shall we? Check it out here)

4.) Pre-populate the cookies

This is a really nice trick.

Every browser you get from Sauce Labs is in a clean state. This is great, and you really want this. Even if Fred says you don’t want it, you want it. Tell Fred, “Fred, last night I spent an hour debugging tests, and found out nothing was wrong. You know what the problem was? Someone had installed the fuzzy_warm_critters_asciis browser extension, and it replaced every instance of my javascript with an ASCII cat. I want clean browsers every time.” Do it. Fred will understand.

ASCII cats are so cute!

Who needs javascript when you can have warm fuzzy asciicatz?

But this poses a bit of a problem with shorter builds, because now each browser session has to go through a login process, and possibly a few more steps depending on your application logic, just to get to where you want to test. Previously, I simply recommended abstracting the login process into a separate method so that the tests looked cleaner, but when you’re waiting for the build to finish, that’s not good enough. You want them clean *and* fast. One way to get this is to set the cookie via Selenium after the browser starts up.

Log in to your user via server-side logic (e.g. generate a row in your sessions table, or however you have it setup locally), generate a cookie for that login session, and push it into the browser via Selenium. Bam. You’re done logging in, and your test can continue on as though it had already spent the 5 seconds logging in and the 10 seconds adding items to the shopping cart, all so you can just test the “confirm purchase” button works on your site as expected in IE7.

This isn’t to say that you shouldn’t test out your login form or your “add fuzzy critter to cart” logic via browser tests. Because you should. But you shouldn’t do it for every test. Test it once, test it good, and leave it at that.

This works on anything that relies on state to be built up. Logins, Shopping Carts, Playlists, etc. You get a clean browser for every tests, and your tests are speedy. And you know what? Even Fred’ll love it. And that – in and of itself – is worth it.

Got any tips on how you speed up your Selenium builds? Take us to school and share ‘em. We’re all ears!

Oh, and for Fred’s sake…

|\      _,,,---,,_
 /,`.-'`'    -.  ;-;;,_
 |,4-  ) )-,_..;\ (  `'-'
 '---''(_/--'  `-'\_)
Share

Selenium 2 Webinar: The Next Generation of Web and Mobile Application Testing

February 10th, 2011 by Ashley Wilson

Curious to know more about Selenium 2? Join Jason Huggins, creator of Selenium, for a webinar devoted to covering the essentials of this new testing tool that combines the best of WebDriver and Selenium.

Here’s a run-down of what you will learn next Wednesday, 2/16, at 10am PST:

  • iPhone and Android testing – See how Selenium 2 allows you to use built-in Android and iPhone emulators to test versions of your applications on the most popular mobile platforms.
  • Cleaner API for IDE users – Selenium introduces a simplified interface for IDE users that directs you to focus on only two basic objects to construct tests: WebDriver (browsers) and WebElements (anything on a web page). In Selenium 2, every API library is now tailored to each programming language for easier usability.
  • Enhanced scalability – The new Selenium 2 architecture allows developers and QA teams to “scale up and down”. For a single test on a local machine, you no longer need a background server. But when you want to scale up to run tests across multiple machines with multiple browser configurations, Selenium has all the power you’ll need.
  • Improved architecture – The new Selenium 2 architecture has enabled the introduction of a number of features that developers and QA pros will love, including native keyboard, support for mouse events, improved capabilities for handling pop-ups, and more stable browser control.

To join us, please click here to register. If you were wondering if Sauce Labs supports Selenium 2 testing the cloud, the answer is yes :-)

See you next week!

Share
Posted in General, Webinars

Advanced Selenium Synchronization with ‘Latches’

February 7th, 2011 by Adam Goucher

Synchronization with Selenium is the number two problem I see with people’s scripts (the first being broken locators). This is actually a pretty easy problem to solve in all but the most pathological situations.

Web 1.0
Remember the good ol’ days when clicking a link caused the browser to fetch a new page? Those were, and remain, super easy to synchronize with using waitForPageToLoad and its language specific variants. Here’s an example of this in Ruby:

@selenium.click "link=click here", :wait_for => :page

Web 2.0
But along came Web 2.0 and all its AJAX-y ‘goodness’. No longer could we be guaranteed that some action or event on the page would trigger a page load. For that, we needed to use a combination of isElementPresent or isVisible.

@selenium.click "link=click here", :wait_for => :element, :element => "my locator"
@selenium.click "link=click here", :wait_for => :visible, :element => "my locator"

While I haven’t done it yet for Ruby, I often combine the two together to create an ‘available’ condition to make sure that the element I care about is both present and visible. Something like this.

@selenium.click "link=click here", :wait_for => :available, :element => "my locator"

Post Web 2.0
Some AJAX calls affect multiple elements and are both tricky and/or time consuming to figure out all the places to watch. New technologies like COMET also make element availability more fallible than it might originally be. For these situations you need to use a ‘latch’ for synchronization.

A what?

The term ‘latch’ in this case is a value that is set in the browser’s DOM that your script monitors for synchronization rather than something in the actual page. And example is in order. Here is an AJAX call in Ruby on Rails.

<%= link_to_remote( "click here",
                   :update => "time_div",
                   :url => { :action => :say_when },
                   :before => "window.latch = 'started'",
                   :complete => "window.latch = 'done'") %>

What this will do is set window.latch to the string value ‘started’ in the DOM before it actually executes and will set it to ‘done’ after it is complete. No problem. People who work with AJAX are used to working with callbacks. The twist happened in our Selenium script.

@selenium.click "link=click here", :wait_for => :condition, :javascript => "window.latch == 'done'"

Now instead of checking for an element to be present or visible, we are waiting via waitForCondition for the latch conditions; in this case, ‘window.latch is done’.

I consider the latch technique as the synchronization method of last resort since it requires changing production code to support automation. But successful automation often calls for just that.

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
« Older Entries
Newer Entries »