Posts Tagged ‘selenium ide’

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

How To Minimize The Pain Of Locator Breakage

September 29th, 2010 by Adam Goucher

In the Agile world, a common saying is ‘never break the build.’ But this thought can actually hinder agility if taken too literally. Sometimes, you want the build to break, as that means things are changing and progressing.

A better phrase is ‘don’t leave the build broken’. The same could be said for Selenium and element locators. They will break, and we want them to…periodically. The measures that count are:

  • How long it takes to go from broken to fixed – this should be small; really, really small
  • How big is the change to fix them – ideally, only one line per element. Total. Throughout the whole code base.

So how do we go about fixing these intermittent breakages?

The easiest locator to use is ‘id.’ To be most successful with this strategy, a static id attribute is put on each html element being interacted with. And since we don’t know what elements will be needed to automate in the future, it’s best to put an id on every element. The scripts will always know how to find the elements on the page uniquely, as WSC standards require that ids be unique in a single page.

While this solves the html structure change problems that often come from using XPath and CSS selectors by finding elements independently of their position, it still doesn’t solve id change issues. Solving that requires discipline and communication among the development and automation teams. One geographically dispersed team I worked with created the following two-part policy for this.

  1. Anyone can add an id to an element that does not have one
  2. If you change an id, the change must be communicated to both the dev and automation teams

Of course, knowing about a change is a bitter pill to swallow when it involves updating hundreds of scripts. A better solution is to separate the locator definitions from the main test code.

Selenium IDE

Separation of scripts from locators is achievable in Selenium IDE through the use of user-extensions. A previous Sauce Labs blog post, Parametrizing Selenese tests, explains how to make use of these extensions, but rather than provide the ‘Value’ column, the ‘Target’ is what could [should] be provided by the user-extension.

storedVars["registrationFirstname"] = "first";
storedVars["registrationLastname"] = "last";
storedVars["registrationSubmit"] = "register";

A script that interacts with a registration form might look like:

open /registration
type ${registrationFirstname} fred
type ${registrationFirstname} flintstone
click ${registrationSubmit}

Going back and updating Selenese scripts is a pain, but using user-extensions to provide the locators to your scripts makes it as simple as updating an external JS file.

Selenium RC

Most Selenium RC languages have a way of reading run-time properties from external files in some native manner:

  • Java – Properties
  • Python – ConfigParser or maybe just python dictionaries
  • Ruby – YAML
  • C# – App.Config

If you’re writing your scripts in Java, you should create a locators.properties file, which would include something along the lines of:

# uses the id locator
registration.firstname=firstname
# xpath
registration.lastname=//form[@name='lastname']/input[@type='text'][2]
# css
registration.submit=css=form submit

Here is a Java class that interacts with our very simplistic registration form, and uses the external properties file (above) for its locators.

import java.io.InputStream;
import java.util.Properties;

import org.junit.Before;
import org.junit.Test;
import org.junit.After;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;

public class TestRegistration.
{
    private Selenium selenium;
    public static Properties locators = new Properties();

    @Before
    public void setUp() throws Exception
    {
        InputStream is = TestRegistration.class.getResourceAsStream("/locators.properties");
        locators.load(is);

        selenium = new DefaultSelenium("localhost", 4444, "*firefox", "http://localhost:3000");
        selenium.start();
        selenium.setTimeout("90000");
        selenium.windowMaximize();
    }

    @Test
    public void testVisibleElement() throws Exception
    {
        selenium.open("/registration");
        selenium.waitForPageToLoad("30000");
        selenium.type(locators.getProperty("registration.firstname"), "fred");
        selenium.type(locators.getProperty("registration.lastname"), "flintstone");
        selenium.click(locators.getProperty("registration.firstname");
        selenium.waitForPageToLoad("30000");
    }

    @After
    public void tearDown() throws Exception
    {
        selenium.stop();
    }
}

Notice there are no hardcoded locator strings in the test, so we can change locators without changing the script. And if a consistent, well-thought-out naming convention is used for the property names, it CAN actually increase the readability of the scripts.

By using the same locators.properties throughout the whole suite of scripts, a single change will cascade to all scripts. It also means that as ids become available on elements that didn’t have them previously, they can quickly be replaced with more structurally dependent methods, such as XPath and CSS. A further benefit is that, by quickly scanning the file, one can determine where in the suite XPath is still being used; converting from XPath to CSS is currently a recommended practice for performance reasons.

Page Objects

Page Objects are a way of representing a web page as a class (or number of classes) to bring Object Oriented techniques and patterns to Selenium. Most Page Object patterns have the locators abstracted out of the actual Page Objects and into a higher level parent class. But even then, those locators should be loaded from an external mechanism to allow for locator changes without recompilation.

Page Objects are beyond the scope of this article, but for an introduction and a sample implementation pattern of them in Python, see Page Objects in Python – Automating Page Checking without Brittleness.

Next Steps

Separating scripts from the locators being used is an important step towards reducing the amount of time teams invest in keeping their automation running. Too often, though, teams jump on this idea and invest valuable time converting their whole suite, which sets them further behind what the features development is producing. A better solution for the team is to collectively decide that scripts and locators will be separate, and from then on, only create scripts in this model, and only backport the abstraction of locator string when they break in existing code. The scripts will be ‘hybrid’ for a time, but ultimately it’s a much faster approach.

Share

How to Automate Testing of your Flash and Flex Apps

August 11th, 2010 by Ashley Wilson

A few weeks ago, we announced the Sauce Flash/Flex Testing System, a new and innovative way to automatically test your apps built with Flash and Flex.

The first functional testing product to support test automation for hybrid web apps, Sauce Flash/Flex Testing System bundles Flex-Pilot’s object explorer API into Sauce IDE, and uses Sauce OnDemand to run tests across multiple browsers in the cloud.

Flex Pilot co-creator Adam Christian, a developer here at Sauce Labs, recently led an informative webinar demonstrating how to setup and use this complete testing system. Watch the video below to learn how easy it is to start testing your Flash and Flex apps today!

Share

The Over-Exaggerated Death of Flex and Flash

July 20th, 2010 by Jason Huggins

The war between Adobe’s Flash and Apple’s support for HTML5 continues to heat up. The first set of battles between Apple and Adobe have reached a standstill for the moment. Adobe is pushing Flash for Android (which is awesome, on my new Google Nexus One, by the way). Meanwhile, the Apple-backed SproutCore project makes HTML5 a viable platform for developers to adopt today.

In spite of the Apple marketing machine, we’re betting that Flex and Flash still have their parts to play in the future of the web. After all, how can we just forget about the massive installed base? Flash is now on 98 percent of computers. More importantly, Flex and Flash have comprehensive tool sets that developers still need. Flash is the single browser plug-in that provides consistency for a chaotic and scattered web world. There are things that HTML and Javascript can’t do well, like webcam capture, media-streaming, and full-screen video. And let’s not forget — a huge segment of the web is gaming, which wouldn’t be possible (so far) without Flash. As YouTube recently noted: “While HTML5’s video support enables us to bring most of the content and features of YouTube to computers and other devices that don’t support Flash Player, it does not yet meet all of our needs.” Should we just abandon everything that we’ve known for HTML5 because it is new and exciting?

I’ll admit that even I have drunk the Apple Kool-Aid and see HTML5 for its role in the future of the web. Sauce specializes in cross-browser web app testing and HTML5 is easier to integrate with Selenium. However, the web is bigger than HTML and JavaScript. HTML5 is the future, but we live in the now. Though growing, HTML5 does not yet have the adoption that Flex and Flash have.

It’s this installed base that Sauce Labs is committing to with our announcement of the Sauce Flash-Flex Testing System.

The newest Selenium-based solution, the Sauce Flash-Flex Testing System provides testing of Flex applications on the Flash platform. Other tools in the marketplace can only test Flex applications, but the Sauce Flash-Flex Testing System covers the entire Flash platform. While Flex is a great tool for many developers, the two biggest markets on the web — gaming and advertising — are based on Flash, not Flex.

So, while we’re all excited for HTML5, rumors of Flash’s death are greatly exaggerated. Demand for Flash wont die. To a lot of people, Adobe may seem like yesterday’s news. But since not everyone has an iPad or an iPhone, the answer is still Flash and Flex, even if it’s not the new hotness.

To this strong base of Flex and Flash users: try out our Sauce Flash-Flex Testing System and give us your feedback.

Share

Selenium IDE 1.0.6 is released!

March 26th, 2010 by Adam Goucher

Selenium IDE 1.0.6 is now available. For those of you running 1.0.5, the update will automatically be pushed to you over the next couple days, and the rest will have it once we point AMO at the installer. If you are new to Selenium IDE then you can…

Download Selenium-IDE 1.0.6 now

The most important bug fix this release is the log message that was displayed in red (scary!) when executing an open command. Other than that, it was mainly just some incremental stuff. Here are the top 3 changes in terms of what I think most people care about.

  • Deal with new Open semantics – Under normal usage, the open command takes just a Target, but now you can also give a Value. If you provide anything other than ‘true’ it will do an AJAXy HEAD request to the server to determine whether the resource is on the server. There was a bit of an issue with the on/off logic that was causing this to be triggered inappropriately resulting in the error message and in some cases errors on the web server (when they had not configured how to deal with HEAD requests). I believe we have fixed this.
  • Type ahead – Some people using Firefox 3.6.x were seeing errors when using the command type ahead. That should work without error now.
  • Default Record Status – It always bugged me that Se-IDE was recording as soon as it opened. There is now a preference for controlling that behaviour

To see the full release notes and who contributed what, visit the Google Code wiki. Also on the Google Code site is the Issue Tracker for any problems you find. (Just make sure you tag them as ide.)

Share

Selenium Tips: Parametrizing Selenese tests

March 12th, 2010 by Santiago Suarez Ordoñez

Even though I believe Selenium IDE should just be a transition environment for new Selenium users to reach Selenium RC, we know a lot of our users keep all their tests in Selenese and run them using Selenium IDE as their main testing tool.

That’s why at Sauce we have developed Sauce IDE, our own extension of Selenium IDE that combines Selenium RC’s cross-browser capabilities with the simplicity and interactive design of Selenium IDE.

To continue empowering the IDE users, I’m writing this tip of the week that will help making Selenese tests easier to maintain and write.

As you all know, Selenese is not a real programming language. Variable storage in it is pretty rough and there isn’t an easy way to share information between different Test Cases in the same Test Suite.

However there is a way to do it, through the use of the user-extensions.js file. Let me show you how in two easy steps:

First, create a user-extensions.js file with the following content:

storedVars["url"] = "/staging/search";
storedVars["title"] = "Search Your Item";
storedVars["search-string"] = "234234kjkj";

Then open Selenium IDE, or even better Sauce IDE, and in the Options menu, select the file in the “Selenium Core Extensions” field.
Close and open Selenium IDE again and you should be ready to use that variable in any test that you write. Even better, throughout your whole test suite.

For example:

open ${url}
assertText h1 ${title}
type search-field ${search-string}
click btnSearch
assertTextPresent Search Results for ${search-string}

This may not look super useful at first, but once your test suite grows, keeping things that change from time to time in a single place, makes it really easy to maintain, so if your application’s URL changes from “/staging/search” to “/search”, you will only need to fix the user-extensions.js file and all the hundreds of tests you could have will pass the same way as they did before.

Check the wikipedia’s page on DRY for more information about this programming technique.

Hope you found this useful. If you did, please let us know in the comments.

Santi

Share

Selenium IDE 1.0.5 is released!

February 19th, 2010 by Adam Goucher

One month (to the day!) after the release of Selenium IDE 1.0.4 was released, 1.0.5 is now available.

Download Selenium-IDE 1.0.5 now

This release fixes a couple really annoying bugs that were introduced in 1.0.4 and starts to build towards the future. Here are the highlights.

  • Self-hosting – Se-IDE will not longer be relying on addons.mozilla.org to be hosting updates. This gives the project more flexibility around when releases are available to users.
  • Back into main project – The code for Se-IDE was in a separate subversion branch than the rest of the current Selenium project which meant its visibility to other developers was lower and that changes were not easily propagated. Se-IDE now lives in the main project so will reap the benefits of the rapidly changing core.
  • User Formats work again – In 1.0.4 there was a bug which meant that while you could add a custom format it would not appear in the list. This has been fixed.
  • Version Display – The version of Se-IDE now appears in the title bar
  • Reload Extensions – A tweak was made to the ‘reload user extensions’ functionality introduced in 1.0.4 so the toolbar button only appears when you have turned it on.
  • Bool Preferences – Preferences used to only be string values, even when a boolean would have been a better choice. Well, now you have a choice about whether you want your preference to be a string or bool.
  • Plugins Pane – There is a new pane in the Options screen called ‘Plugins’. This will become the central means of managing plugins in future releases, but for now it doesn’t do much aside from listing which plugins have registered themselves with the (also new) addPlugin(id) API function.
  • Icons – You will see a couple icons now in Firefox for Se-IDE rather than the default ones. Such as in the main Extensions window and in the Tools menu
  • For the full release notes and who contributed what, see the Google Code wiki. Also on the Google Code site is the Issue Tracker for any problems you find. (Just make sure you tag them as ide.)

    And as before, thanks to Sauce Labs for sponsoring my work on this release.

    -Adam Goucher

    Share

Ridiculously easy cross-browser testing with Sauce IDE

January 20th, 2010 by Jason Huggins

Riding on the coattails of yesterday’s official Selenium IDE 1.0.4 release, we’re very excited to announce Sauce IDE 1.0 (beta 1). Download it here. Sauce IDE is Sauce Labs’ certified, enhanced and commercially-supported version of Selenium IDE.

With Sauce IDE, we’ve made cross-browser cloud testing ridiculously easy. After you record a test in Sauce IDE, you’re only one click away from replaying that test on any major browser on Windows or Linux. Sauce IDE allows users to tap directly into our Sauce OnDemand cloud-hosted Selenium service while getting access to a sophisticated Selenium test infrastructure without having to build and maintain the infrastructure yourself.

Another really cool feature is video recording and playback. With every browser test you run with Sauce IDE on the Sauce OnDemand cloud, you can view or download a full screen video of your test.

Sauce IDE is a plugin for Firefox, and we’ve also included Firefox 3.6 support in our latest release.

Here’s a quick screencast showing how easy it can be to start running cross-browser tests in the cloud.

- Jason Huggins

Share

Selenium IDE 1.0.4 is released!

January 19th, 2010 by Adam Goucher

Since my work on Selenium-IDE was sponsored entirely by Sauce Labs, it makes sense to announce the newest release on this blog.

Download Selenium-IDE 1.0.4 now.

1.0.4 is the first release with new features in quite some time, and hopefully marks a renewal of the project. I’m going to try and push out a new build mid-month so get your bugs, patches and feature requests in.

So what is in the 1.0.4 release? A good question…

  • Firefox 3.6 – The previous release of Se-IDE worked with Firefox releases up to and including the 3.5 series of browsers. This version enables support for the 3.6 series of releases by default so people don’t have to do some of the hacks that are floating around.
  • Removed deprecated formatter – There was a Ruby formatter that had been marked as deprecated for a while in Se-IDE. It has been removed. If you are exporting from Se-IDE to Ruby, you should be using the officially supported Ruby formatter.
  • Update to Ruby formatter – The officially blessed Ruby Se-RC client is the selenium-client gem. The Ruby formatter has been updated to use its format.
  • RSpec – Ruby, ruby and more ruby. RSpec is now part of the standard set of formatters Se-IDE ships with.
  • Reload user-extensions – Jérémy Hérault has solved a problem some more advanced Se-IDE users experience by adding the ability to reload user extensions without having to restart Se-IDE. To enable this feature, check ‘Activate Developer Tools’ in the Options screen.
  • API – In order to help kick-start more companies using Se-IDE as their testing platform, Se-IDE has started to grow an API that other addons can use. Think of this as the Firebug model where Se-IDE will provide the structure, and other groups will provide additional functionality and features. Here are the first two things the new API can do.
    • Extend the Selenium API – There is a community of developers who have extended the Selenium API so new commands can get added to the IDE’s command list. (I’m a big fan of the Random String one.) You can now bundle user extensions up as a plugin to Se-IDE.
    • Formatters – Se-IDE ships with a number of default formatters that it can display or export to. But what if the language you use isn’t listed, or you have a custom test runner that requires different information? The solution to that has always been to install a custom formatter, but making sure that everyone in the group has the current, correct version installed is a pain. Instead, you can now put your custom formats in a plugin that is distributed to people.

    The documentation for this API is still very much a work in progress, but this series of blog posts should be enough to get people started on it. Eventually it will be rolled into the Official Selenium Documentation.

For issues with this release or features you would like to see in future releases, please log them in the Google Code Issue tracker using the label ide.

This release has also been submitted to addons.mozilla.org to be distributed through the normal plugin update system. We do not have any control over how long it will take for that update to be processed and released. For those who need it now, here is the direct download link on SeleniumHQ.

-Adam Goucher

Share