Getting started with Selenium Remote Control - Part 2

Have you been meaning to learn an automation test tool? Selenium RC is an open source tool that you will be able to learn in no time. This tutorial will cover Selenium RC through Perl scripts, a powerful free web-application tool suite. Part 1 covered the installation instructions of all the necessary software to get your environment running. Part 2 will cover what to do once the software is installed, explaining more about the capabilities of the tools.

Table of Contents

Just the facts Ma'am
Selenium is essentially a set of tools that allow us to drive a browser, and inspect its progress along the way. We can then click, type, click, and confirm the data in the browser, all without a human watching. There are even tools to summarize a long test run into meaningful statistics.

Let's take a look at the commands of the searchamazon.pl Perl script that was used in Part 1 of this tutorial. These are Selenium commands that can be used within Perl because we've installed the Test::WWW::Selenium package in the Perl Package Manager. For the most part, they are standard selenium commands plus _ok, which makes an assertion that outputs a pass or fail result. The following commands open up amazon.com, look for the search box, and search for "Beautiful Testing," a book I contributed a chapter to last year.

Notice that in order to click on a web element we need to identify it. By web element, I mean an HTML element. The raw HTML web page code looks something like this:

<input type="text" title="Search for" size="50" value="" id="twotabsearchtextbox">

Related Content: Podcast: Using Selenium for application testing Matt Heusser explains how to use Selenium an open source testing tool that supports Java scripting within Web browsers. How to use Selenesse, a combination tool from FitNesse and Selenium Selenesse is an open source project that lets testers drive browsers with Selenium, but manage and run their tests in the testing framework Fitnesse.

Notice the id "twotabsearchtextbox." Every element on a Web page is identified with a unique id. We can find the id of an element by right-clicking and viewing source, or downloading a tool like firebug that provides information on any element by a right-click/'inspect-element.' In order to test Web applications with id, we need to create a unique id for each element that we must know in advance. In cases where it's difficult to determine the id of an element, we can use a special language called xpath to find elements. For example, //input[@alt='Go'] means look for the first input element with an alternate 'nickname' of 'Go.'

Those are some basics of the command language. The core of Selenium is the ability to call these commands from several different programming languages - Perl, Ruby, Java, Python, even .NET languages. Most of these languages have slightly different styles; I've coded my examples in Perl. With this framework in place, we can hire programmers to create entire 'testing' programs, or build power functions and abstract away the commands, so they read like the example above.

This article covers Selenium RC, a 'server' that sits and monitors for requests to drive the browser. It also covers how to write programs to send requests to that server, and evaluate the response. There are many other selenium tools, such as Selenium IDE. Selenium IDE is a bit easier to get started but harder to extend and scale out.

If you've gone through the sample test program from Part 1, you're probably hungry for more.

Key selenium commands
To build a real test set, you'll need more choices. Here are a few of the most popular commands for Selenium RC in Perl:

You can find a more complete introduction in the documentation for WWW::Selenium, or in the main selenium documentation for Java, Ruby, or Python.

Creating our test framework
Writing programs to test programs can be like building on shifting sands; when the underlying program changes, all of the tests break. One solution is to create higher level functions that function like commands - for example, login, perform a search, expect a search result to appear in a certain place and so on.

Now, for just a moment, let's compare the table-code I wrote at the top of the article to the perl executable code here. Think about what that executable code will look like for a 'real' test – a non-trivial test of a serious application. It would have loops, variables and calculations in, and be perhaps a hundred times as long. The test program itself quickly becomes a monster program.

Pretty soon, your tests need tests.

The Perl script we have so far is fine, but if possible, I'd recommend abstracting it, moving toward the first example.

There are several ways to do this. For example, the developers can create a framework that takes a file, reads it in, parses it for commands, and runs those commands against a selenium object. With a little more work that framework can read an entire directory. With that framework in place, a tester can create simple data-driven tests (like the one at the top of this tutorial) instead of programming a complex language. Combine that with a little TAP parsing, and you've got automated test execution, reports -- and your tests are written in a high-level language that customers are likely to actually understand. While a good programmer should be able to run through this tutorial over a lunch hour; it might take a day or two to design a framework to do this work.

Of course, recording tests takes a relatively large amount of time; they only do exactly what they are told, and only check for what we ask. Any senior tester will tell you that some of the best bugs are found from varying the script -- or by noticing changes that no one explicitly told you to look for. So testing with Selenium RC can be one part of a balanced breakfast, a good quick "smoke test" to check for regression.

And that completes this tutorial. Until next time, happy testing!

About the author: Currently a technical staff member at Socialtext, Matt Heusser has been developing, testing or managing software projects for over a decade. He teaches information systems courses at Calvin College and is the original lead organizer of the Great Lakes Software Excellence Conference, now in it's fourth year. You can read more of Matt's writings on his blog, "Testing at the Edge of Chaos".

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.