Sauce OnDemand Now Supports Selenium 2.1.0

August 1st, 2011 by Santiago Suarez Ordoñez

In keeping up-to-date with the releases pushed by the Selenium project, Selenium version 2.1.0 is now fully available in our service.

This new release includes a mayor fix to an important bug affecting some native clicks on elements. You can check out the official changelog for more information.

Due to our new release process, there will be a testing period before we make this the default version in our service. (Once we’ve decided to do so, we’ll announce it in advance). In the meantime, we advise you to try out your tests in this new version using the following Desired Capabilities/JSON key-value:

"selenium-version": "2.1.0"

We’d love to hear if you see any issues after moving your tests to Selenium 2.1.0. And stay tuned, as we’ll be announcing 2.2.0 as well as other versions through our blog too!

Share

Tips From Our Codebase To Help You Write Reliable Selenium Tests

July 26th, 2011 by Santiago Suarez Ordoñez

As part of our new “Test Like A Ninja Webinar Series,” I held an improv webinar last week that covered how to write better Selenium tests. Most of the content came from my own Selenium experience, as well as experience gleaned from working on our own customers’ issues.

Without further ado, here’s the video:

And here are some of the code snippets I talked about:

Implicit waits in Selenium 1:

Ignoring Open and waitForPageToLoad failures, as well as reporting pass/fail status automatically:

Reporting pass/fail status automatically on python for Selenium 2 tests

Tune in to the next Test Like A Ninja webinar on August 2 to learn how easy it is to test behind a firewall in the cloud.

Happy testing!

Share

Lessons Learned: Migrating from Selenium 1 to Selenium 2

July 21st, 2011 by Roger Hu

This guest blog post was written by Roger Hu, Software Engineer at Hearsay Social.

At Hearsay Social, we’ve upgraded our testing environment to use Selenium 2. We made the switch because there was enough evidence to suggest a huge 2-4x performance increase. Having learned a few lessons along the way, we thought it would be helpful to share what we found, especially for those who are considering making the transition.

  • Since Selenium 2 is redesigned to leverage what works best for the browser, whether it’s a NPAPI plugin in Firefox or a DLL module for IE, we’ve discovered a huge performance gain, especially in Internet Explorer (IE) browsers that have much slower JavaScript engines. The new approach seems to allow us to run Selenium more conveniently on Internet Explorer browsers without the hassle of changing the security options because of all the exceptions that were thrown as a result of the older JavaScript-based architecture.
  • Selenium 2 gets closer to simulating the behavior of a user on a browser.  In Selenium 2, the DOM element that is actually clicked is determined by the X/Y coordinates of the mouse event. Therefore, if you attempt to search for a DOM element that is hidden or obstructed by another element, the top element will always be fired and you might encounter ElementNotVisibleException errors from the Selenium server. You need to keep this issue in mind when rewriting your tests, since Selenium 1 versions may not have had this restriction. (We use the Django web framework and the popular django-debug-toolbar, which adds a popup overlay in our web application that has to be disabled in our application during Selenium tests.)
  • We’ve found that the new Selenium 2 WebDriver-based API is easier to train our developers to use. The documentation for Selenium 2 is still somewhat sparse, especially for the updated Python bindings, so digging into the source code (in our case, remote/webdriver.py and remote/webelement.py code) is still the best way to learn what API commands are available. While Java developers may have access to WebDriverBackedSeleniumclass that can use existing Selenium 1 code while leveraging the WebDriver-based API, we didn’t find any similar support for Python. So we took the plunge and refactored most of our tests.

    webdriver/remote/webelement.py:

     @property
        def tag_name(self):
            """Gets this element's tagName property."""
            return self._execute(Command.GET_ELEMENT_TAG_NAME)['value']
    
        @property
        def text(self):
            """Gets the text of the element."""
            return self._execute(Command.GET_ELEMENT_TEXT)['value']
    
        def click(self):
            """Clicks the element."""
            self._execute(Command.CLICK_ELEMENT)
    
        def submit(self):
            """Submits a form."""
            self._execute(Command.SUBMIT_ELEMENT)
    
        def clear(self):
            """Clears the text if it's a text entry element."""
            self._execute(Command.CLEAR_ELEMENT)

On the server-end, it’s important to study how the client API is sending remote commands by reviewing the JsonWireProtocol document posted on the Selenium Wiki, especially since Sauce Labs provides you with the raw logs to see what commands are actually being issued by the client.

  • While experimenting with Selenium 2, we found it much easier to test out the new WebDriver API by downloading and running the Selenium server locally. This way, your connection won’t constantly timeout as a result of using your Sauce Labs account, giving you more freedom to experiment with all the various commands. If you need to run browser tests against an external site while using your own machine to drive the browser interactions, you can setup a reverse SSH tunnel and then experiment with Selenium 2 API by setting debugger breakpoints and testing out the API bindings. In the long-term, though, you definitely want to use Sauce Labs for hosting all the virtual machines in the cloud for running your browser tests!
  • If you’re interested in using Firebug to help debug your application, Selenium 2 also provides a way to inject Firefox profiles. You can create a Firefox profile with this plug-in extension, and Selenium 2 includes an API that will base-64, zip-encode the profile that will be downloaded by the remote host. Note that this approach works best if you’re running the Selenium server locally, since using it over a Sauce Labs instance only gives you access to view the video.
  • Selenium 2 continues to be a moving target with its API, so you’ll want to keep up to date with any release notes posted on the Selenium HQ blog. Most recently, we found that the toggle() and select() commands have not only been deprecated but removed completely from the implementation. If you try to issue these commands, the Selenium server simply doesn’t recognize the commands and WebDriverExceptions are raised. The best thing to do is look at the Selenium version number. In this particular example, version 2.0.0 (three decimal places) are used to represent the release candidate of the latest Selenium build. You may also instantiate your .jar files with the -debug flag to watch how your client bindings execute API commands to the Selenium server.
20:38:02.687 INFO - Java: Sun Microsystems Inc. 20.1-b02
20:38:02.687 INFO - OS: Windows XP 5.1 x86
20:38:02.703 INFO - v2.0.0, with Core v2.0.0. Built from revision 12817
  • Selenium 1 users will find that is_text_present() and wait_for_condition() commands no longer exist, and are replaced by a more DOM-driven approach of selecting the element first before firing click() events or retrieving attribute values through get_attribute(). You no longer have to have wait_for_condition() for page loads. Instead, you set implicitly_wait() to a certain timeout limit to rely on find_element_by_id() to wait for the presence of DOM elements to appear to between page loads.
  • Lastly, we’ve noticed in the Selenium discussion groups that often there are questions about how to deal with concurrent Ajax requests during your tests.  In many test frameworks, there’s the concept of setup and tear down of the database between each set of tests.  One issue that we encountered is that if your browser is issuing multiple requests, you’re better off waiting for the Ajax requests to complete in your tear down function since the requests could arrive when the database is an unknown state. If this happens, then your Selenium tests will fail and you’re going to spend extra time trying to track down these race conditions. If you’re using jQuery, you can check the ajax.global state to determine whether to proceed between pages (i.e. execute_script(“return jQuery.active === 0″)). You’ll want to keep looping until this condition is satisfied (for an example of implementing your own wait_for_condition() command, click here.)

Hope you find these tips helpful for migrating over to Selenium 2. Happy testing!

Share

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

Appeasing the Butler or The Commit Heard Round the Company

June 28th, 2011 by joe

Sauce Labs does not employ any artists

 

This is what our build looked like. He was not happy. Notice how his eyes are red. That’s because of failing tests, which as we know turn builds red. These failing tests weren’t normal failing tests, which are actually pretty happy, because they are telling you how to fix your broken stuff. No, these tests were intermittent. That’s largely the fault of the fact that they were selenium tests – go figure, the selenium shop that sells selenium as a service is having selenium issues, lol (but sadface).

Well, to get out of sadfaceland, we dug into one of the sadtests and saw something surprising. It was a case of selenium looking for an element before it appeared. Wait, what? We already know how to fix that. In fact, we already told the whole world how to fix it: with spinning! Basically, the way a spinassert works is by trying the assertion over and over until it passes. This is a big deal with selenium because trying to interact with an element on a page before the page has loaded is a frequent source of flakey tests. We even went so far as to write Test::Right (source on github), a ruby test framework which goes out of its way to make it impossible for you to do write selenium tests without spin asserts. So what happened?

Well, we don’t use Test::Right for all our own tests. Test::Right is ruby and our tests are written in the same language as our back-end; python. And while we were using spin-style asserts for many of our tests, some of them were written before we discovered the magic of spinning, and some were written when we just didn’t remember to use spinning. Also, there were some things that were not assertions but still required spinning; like, if you want to click on an element in a page, it makes sense to spin-wait for that element to be present before clicking on it. Test::Right does the right thing in all these cases; we just had to be more like Test::Right in-house, to prevent sadness from creeping back into the codebase again.

So the fix was clear: modify our own test framework to always spin-wait all the time for every DOM element to show up, every time anyone tried to interact with a DOM element, automatically. We did that, and it made the butler happy. All of a sudden we could trust the build again, and it didn’t take hours to wait for a nonflakey build so that we could deploy new changes. This in turn meant that we never had to hotpatch production when there was an issue, which meant we didn’t have to spend time cleaning up hotpatches when a deploy happened. It also unblocked people who wanted to push new changes to trunk. Basically the whole dev process got better.

So here’s the thing – our customers are having the same issue. Not everyone uses Test::Right. We know this because we have a support team and customers contact us all the time asking for help with flakey tests. In our over 3,000 support requests, race-condition flakey tests are the #1 cause of pain. The shocker is that except for Test::Right (and now our own internal python nose framework), nobody has this universal fix.

So we’re hoping to make test frameworks for all the common languages – PHP, Java, Python, at least – that do what Test::Right did. We already have our own PHPUnit extension (thanks Jan Sorgalla!) which will probably be the first to get the Test::Right makeover.

Sadly, we are a focused team, and we have many tasks to accomplish, so this fix to selenium client libraries will likely not be imminently released by us. Thus we decided to at least tell you all how to Fix Everything on your own side. Now that I’ve done that, back to programming! Good night and good luck.

Share

Why CSS Locators are the way to go vs XPath

May 17th, 2011 by Ashley Wilson

Last week, our own Santiago Suarez Ordoñez gave a presentation to the San Francisco Selenium Meetup group that convinced us all to say no (for the most part) to XPath and yes to CSS Locators in our Selenium tests.

In his role as official Sauce Ninja and as a prolific poster in the Selenium forums, Santi has helped more users solve locator issues than possibly anyone else in the world. He’s previously written a number of blog posts on ways to improve locator performance. As Sauce CEO John Dunham puts it, “If there was a foursquare mayorship for locators, Santi would have it for a lifetime.”

Drawing from this experience, he gave us these four reasons for using CSS Locators:

1. They’re faster
2. They’re more readable
3. CSS is jQuery’s locating strategy
4. No one else uses XPATH anyways!

I can’t speak for everyone, but Santi sure sold me on point number one when he showed off the performance metric script he wrote a script that tested the speed of XPath vs the speed of CSS Locators. There wasn’t much of a difference in Firefox, Safari, or Chrome, but with IE, the results were undeniable. Take a look:

To underscore this even further, he also recorded a video in Sauce OnDemand that uses one heck of a cute kitten to illustrate just how slow XPath can be. The cat’s paw movements represent the test clicking through the different locators. The first batch of clicks uses CSS Locators and completes in under 30 seconds. The second batch, the XPath one, continues on for another eight minutes. Eight minutes!

During the rest of the presentation, Santi dives into writing both basic and more advanced CSS Locators. He also spends some time talking about when you shouldn’t use CSS Locators (yes, there are a few cases where it is not the right tool for the job). To see the talk in its entirety, check out the recording below. And if you’re thinking of switching over from XPath, but unsure of how to go about it, check out the nifty tool Santi wrote called cssify. It does the handy work of translating your XPaths to CSS automatically.

Helpful links
View Santi’s Presentation Slides
Follow him on Twitter
Follow Sauce on Twitter
Join the San Francisco Selenium Meetup group!

Enjoy!

Share

How to Lose Races and Win at Selenium

April 12th, 2011 by joe

Selenium races your browser

Selenium tests sometime fail for no reason. You can eliminate most of their random failures with a special kind of assertion, the spin assert. The problem is that Selenium is overeager, and it needs to chill out and wait.

Selenium tests often fail because they’re too fast. Where a user might wait for a page to load for a few seconds and then click on a link, Selenium will interact with a page at the speed of code, before the page is ready. The way to fix this is to have Selenium repeat its actions and assertions until they work. If you don’t, Selenium races your browser.

You need Selenium to lose the race

Selenium tests pages. It tests them by loading them and then doing stuff on them like it’s a person. Isn’t that cute? Selenium thinks it’s people. Unfortunately for us, Selenium isn’t people, and in not being people, it’s too fast. Websites are made for people, with the knowledge that people are slow. When humans open a page, the humans wait for it to be loaded, then click on stuff. The clever secret of webpages is that they’re not really loaded when they look loaded. That’s because the web page’s authors know we take a second to take it all in before we start playing. So they make pages that look loaded right away, and then use javascript to do more real loading once the page is ‘loaded.’ This javascript sets up for playtime in the background while we’re taking it all in. Selenium has a bad habit of trying to use pages before they’re set up for playtime.

The way to solve that is not telling Selenium to pause for a fixed number of seconds. Pauses have two problems. They make your tests slower than they need to be, and they don’t really fix the problem, just make it less frequent. The best solution is to have Selenium keep trying until it works. If your test is trying to assert that clicking on an “email settings” button pops up an email settings dialog, Selenium should repeat a “click the button -> is the status dialog visible?” loop until the status dialog is visible.

Here’s the problem. When we tell Selenium to wait-for-page-to-load and then click, Selenium waits for the wrong thing. It can tell when all the page’s content has been downloaded and displayed, but it has no idea when the page’s custom javascript has finished loading. Sometimes that functional javascript goes back to the server and fetches more content to be displayed, so you can’t even count on required text being present yet. There are several ways for a page to be “loaded,” and Selenium doesn’t wait for the right one. It races your page’s loading logic, often “winning” the race and clicking on things before they’re ready to be clicked on. You need Selenium to lose the race.

Here’s how to do this

 

The solution is spin asserts. At Sauce Labs, when we want to verify that some text appears on a page, we use this function:

def wait_for_text_present(self, text, msg=None):
    msg = msg or " waiting for text %s to appear" % text
    assertion = lambda: self.selenium.is_text_present(text)
    self.spin_assert(msg, assertion)

Do you see it calling a function named spin_assert? That function is the key. spin_assert retries the passed-in test function, in this case a lambda expression, over and over until it works. Here’s what spin_assert looks like, minus some bells and whistles:

def spin_assert(self, msg, assertion):
    for i in xrange(60):
        try:
            self.assertTrue(assertion())
            return
        except Exception, e:
            pass
        sleep(1)
    self.fail(msg)

In this case, wait_for_text_present will repeatedly ask the Selenium server whether the text is present until it shows up. It could do several things in a loop, like click a button and then ask whether a popup has appeared. Almost all the asserts in our internal Selenium tests are a wrap around a call to spin_assert, and they’re all way more reliable than they were before the switch.

Share

Selenium 2 in the news!

April 7th, 2011 by The Sauce Labs Team

“Selenium 2.0, an upgrade to the popular open source Web application testing tool set, is anticipated for release this summer, featuring accommodations for mobile platforms and architectural improvements, its creator said on Tuesday.”

“The upgrade is set to support testing of Web applications that run on Apple iPhone and Google Android devices, said Jason Huggins, who first built Selenium in 2004. Some time after the 2.0 release, Selenium builders hope to add Web application testing for Research in Motion BlackBerry and Microsoft Windows Phone 7 devices. Testing of native device applications also is on the long-term road map for Selenium. “I think it makes sense for us to expand, to be able to do native apps,” said Huggins, who is attending Selenium Conference 2011 in San Francisco this week. Version 2.0 already has been in a beta test phase.”

“Architectural enhancements in version 2.0 will enable Selenium to better deal with testing areas, such as accommodating password popups or security warnings. “There’s a lot of under-the-hood cleaning that we’ve done,” said Huggins, who is co-founder and CTO at Sauce Labs , which offers a cloud-based version of Selenium called Sauce On Demand.”

http://www.infoworld.com/d/application-development/selenium-test-suite-add-mobile-apps-011

Share

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