What is Automated Web Testing you may ask, and how is it done? If you search this topic on Google, you may be well flooded by confusing and overwhelming information from different websites and blog post. But lucky for you, I have done the homework and consolidated those into an easy to understand presentation for you:
Selenium
Selenium automates browsers. That’s it. What you do with that power is entirely up to you. Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should!) also be automated as well.
Here we are using it to automate acceptance test for our web based control panel. We will be triggering those tests periodically and monitor the results. If anything customer facing stops working, we’ll have the first hand and quickly react to issues before they spread or damages company reputation.
Many documents or blogs you find online regarding Selenium are out dated and are only covering the old Selenium. I will be focusing on Selenium 2 with the WebDriver standard which is adopted by major browsers.
Selenium IDE or Selenium Builder
Both Selenium IDE and Selenium Builder are implemented as a Firefox extensions. They allow you to record, edit, and debug your automated test scripts. Selenium Builder was created in the attempt to replace Selenium IDE in the long run and is still in the beta stage as I am writing. Having used both, I prefer to use Selenium IDE because Selenium is crashing a lot.
Selenium IDE
It currently supports both Selenium 1 and 2 (WebDriver) format. It’s able to convert your tests into scripts in the programming languages you use. Here we use Perl and we’ll need to install a plugin provided by the Selenium::Remote::Driver project in order for Selenium IDE to convert test scripts to Perl.
Selenium Grid 2
Don’t be intimidated by the term “Grid”; It simply means a cluster of Selenium servers. The Wiki has full instructions on how to use and configure Selenium Grid 2. Here I am just going to cover what I use on my project. The Grid is consisted with a hub and multiple nodes. The selenium-server-standalone package includes the Hub, WebDriver, and legacy RC needed to run the grid. Ant is not required anymore. You can download the selenium-server-standalone-*.jar from here. This walk-through assumes that you have already installed Java run time on your testing servers.
Grid Hub
The Selenium Hub is the central point that will receive all the test requests from your testing script and distribute them the the appropriate Selenium nodes.
Open a command prompt and navigate to the directory where you copied the selenium-server-standalone file. Type the following command:
java -jar selenium-server-standalone-2.33.0.jar -role hubThe hub will automatically start-up using port 4444 by default. To change the default port, you can add the optional parameter -port when you run the command. You can view the status of the hub by opening a browser window and navigating to: http://localhost:4444/grid/console
Grid Node
Regardless on whether you want to run a grid with new WebDriver functionality, or a grid with Selenium 1 RC functionality, or both at the same time, you use the same selenium-server-standalone jar file to start the nodes.
java -jar selenium-server-standalone-2.33.0.jar -role node -hub http://localhost:4444/grid/registerNote: The port defaults to 5555 if not specified whenever the “-role” option is provided and is not hub.
java -jar selenium-server-standalone-2.33.0.jar -role nodeFor backwards compatibility “wd” and “rc” roles are still a valid subset of the “node” role. But those roles limit the types of remote connections to their corresponding API, while “node” allows both Selenium RC and Selenium WebDriver remote connections.
WebDriver
WebDriver is the new Selenium 2. It takes a different approach to solve the same problem as Selenium 1. Rather than being a JavaScript application running within the browser, it uses whichever mechanism is most appropriate to control the browser. For Firefox, this means that WebDriver is implemented as an extension. For IE, WebDriver makes use of IE’s Automation controls.
By changing the mechanism used to control the browser, we can circumvent the restrictions placed on the browser by the JavaScript security model. In those cases where automation through the browser isn’t enough, WebDriver can make use of facilities offered by the Operating System. For example, on Windows we simulate typing at the OS level, which means we are more closely modeling how the user interacts with the browser, and that we can type into “file” input elements.
Run Tests
My Environment
- OS: Mac OSX
- Selenium Nodes:
- Ubuntu 12.04
- Mac OSX
- Selenium Server Version: WebDriver running on Mac OSX
- Test Scripting Language: Perl
For Selenium (WebDriver) nodes, you will need to use the RemoteWebDriver and the DesiredCapabilities object to define which browser, version and platform you wish to use. Create the target browser capabilities you want to run the tests against. Examples will be under the “Perl” section.
Writing Test Script with Perl
Majority of the examples I found online regarding the use cases of Selenium 2 (WebDriver) are done either in Java or Ruby. Java is out of the question because:
- No heavy IDEs like Eclipse or Netbeans running on my already suffocating Mac OSX
- The need to compile testing scripts seems like a waste of time
- We are a Perl shop at work, I will get much support using the language people are comfortable with
Decision has been made. Let’s take a look at what Perl modules we will need to make it work.
- Selenium::Remote::Driver
- Test::More
Selenium::Remote::Driver
Perl Client for Selenium Remote Driver, it is used to connect to Selenium server (Hub/Node) remotely and send command to the WebDriver API. Install this module with CPAN from your Linux or OS X terminal:
cpan -i Selenium::Remote::Driver Test::More
In your Perl script, load this module at the beginning of the script with the other ones that you would normally use like so:
#!/usr/bin/perl
use strict;
use warnings;
use Test::More;
use Selenium::Remote::Driver;
Here is the full documentation on how to initiate and use Selenium::Remote::Driver module. Use the following in your Perl script to connect to a Selenium hub or node by specifying the server’s IP address, the browser type and/or version you want to test with:
my $driver = Selenium::Remote::Driver->new(
'remote_server_addr' => 'localhost',
'browser_name' => 'phantomjs',
'port' => '5555',
);
Test::More
Yet another framework for writing test scripts. It will generate TAP test results which I can integrate into Jenkins for CI (continues integration) or Nagios for monitoring test results.
Documentation
Browsers
List of supported browser names that you can use in the Perl script.
- iphone
- firefox
- internet explorer
- htmlunit
- iphone
- chrome
- phantomjs
Firefox
Supported by default
Chrome
Require you to install ChromeDriver. To use it in conjunction with Selenium server, start your Selenium server with the following command:
java -Dwebdriver.chrome.driver=chromedriver -jar selenium-server-standalone-2.33.0.jarchromedriver is the actual ChromeDriver executable you’ve just downloaded.
Posts
