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.
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.
|Command||Parameter 1||Parameter 2|
|wait_for_text_present_ok||Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice)||30000|
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">
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:
|Command||Parameter 1||Parameter 2||Notes|
|verify_title_ok||title of page||Confirms the <title> attribute|
|Pause||time_in_miliseconds||wait for something to happen|
|check_ok||element_name||check a radio or text box|
|uncheck_ok||Element||uncheck a checkbox|
|text_unlike||text to look for||make sure it isn't on the page|
|verifyConfirmation||Text||click ok on a yes/no confirm popup|
|location_like||Text||URL in browser should match|
|select_ok||Element||label=text||actual text label to select from a dropdown|
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".