Selenium is an acceptance test tool written by ThoughtWorks especially for web applications.
Selenium tests run directly in a browser, just as real users do. And they run in Internet Explorer,
Mozilla and Firefox on Windows, Linux, and Macintosh. It allows testing in a wide range of
Browser compatibility testing. Test your application to see if it works correctly on different
browsers and operating systems. The same script can run on any Selenium platform.
System functional testing. Create regression tests to verify application functionality and user
The core of selenium, also referred to as browser bot, is written in Java Script. This allows the test
scripts to run inside supported browsers. The browser bot is responsible for executing commands
received from test scripts which are written in either HTML using a table Layout or a supported
Selenium works with the following:-
Internet Mozilla Firefox Safari
Windows XP 6.0 1.6+,1.7+ 0.8+,0.9+,1.0
Red Hat Linux 1.6+,1.7+ 0.8+,0.9+,1.0+
Mac OS X 10.3 Not Supported 1.6+,1.7+ 0.8+,0.9+,1.0+ 1.3+
Selenium IDE is an integrated development environment for Selenium tests. It is implemented as a
Firefox extension, and allows you to record, edit, and debug tests. Selenium IDE includes the entire
Selenium Core, allowing you too easily and quickly record and play back tests in the actual
environment that they will run.
But Selenium IDE is only compatible with Firefox. To make it IE compatible we use Selenium
Selenium can be used in two modes: - Test Runner Mode and Driven Mode.
In Test runner Mode, scripts are completely run inside the browser.In the TestRunner mode of
Selenium you will only be able to test the functionality of your own Web site. You will not be able
to run tests against third party sites such as Google or Amazon, due to the cross-scripting security
In Driven Mode, the test scripts are run partly from outside the browser using driven scripts.
We opted to write selenium scripts in Driven Mode as our products were not compatible with
Firefox. So I will be describing about Driven Mode in details.
Driven Selenium scripts is written in any of the supported programming languages i.e., currently
java, Ruby and python drivers are available.
The scripts run in a separate process outside of the browser. The driver's task is to execute the test
scripts and drive the browser by communicating with the browser bot which runs inside the browser.
The communication between the driver and the browser bot uses a simple Selenium-specific wire
language called Selenese.
Driven scripts are more powerful and flexible than test runner scripts and you can integrate them
with xUnit frameworks. However Driven scripts are more complex to deploy and write as compared
to test runner scripts. This is because the driver has to perform the following tasks:
• Start the server.
• Deploy application under test (AUT).
• Deploy test scripts.
• Start the browser.
• Send commands to the browser bot.
• Verify the result of commands executed by the browser bot.
Driven scripts are more dependent on the application Runtime Environment .Ex – Java uses
embedded jetty or Tomcat to deploy application under test.
Real Time Implementation
I am here going to describe of how to use Selenium Remote Control (SRC) to develop and run you
automated tests. This SRC uses Selenium Server. You can download SRC from the following link
Given below are the configurations that need to be done to develop and run your test using
1. The Selenium Server is written in Java, and so it requires the Java Runtime Environment
(JRE) version 1.5.0 or higher in order to start. Once you are done with the installation of java you
can check it by typing “Java –version” at the command prompt. This will show a brief message
telling which version of Java is installed. The message will be like
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java Hotspot(TM) Client VM (build 1.5.0_07-b03, mixed mode)
2. You need to install any supported language in which you want to write your test scripts. We
preferred ruby as the scripting language to write automated tests in Selenium and so we installed Ruby
1.8.5-21along with its binaries. You can directly download Ruby from http://www.ruby.lang.org
3. To allow IE to accept URLS in the form http://username:password@localhost/loader.aspx we
need to edit registry settings. - iexplore.exe and explorer.exe DWORD values need to be created in
_USERNAME_PASSWORD_DISABLE and their values need to be set to 0.
4. If you are using ruby as the scripting language to develop your test scripts then you need to install
the Hpricot HTML Parser for Ruby gem. You can install it by typing the following command in the
gem install hpricot
You will be prompted with the following selections as seen below.
Select which gem to install for your platform (i386-mswin32)
1. hpricot 0.8 (ruby)
2. hpricot 0.8 (mswin32)
20. Cancel installation
Choose the option - hpricot 0.8 or whatever suits your need (mswin32)
You can choose the hpricot version you want. We preferred the eighth option.
5. The selenium server needs to be started from the command line before executing your tests. There
are several Server Command Line Options to start your SRC in the mode which will be most
suitable for your AUT. The several Server Command Line Options are as follows:-
Usage: java -jar selenium-server.jar [-interactive] [options]
-port <nnnn>: the port number the selenium server should use (default 4444)
-timeout <nnnn>: an integer number of seconds before we should give up
-interactive: Starts the selenium server in interactive mode. Selenium Server "interactive mode" is a
way of rapidly prototyping tests that requires no coding whatsoever, so it's a good way to introduce
new users to Selenium Remote Control. In interactive mode, you type your commands one by one
into the Selenium Server command window; this allows you to immediately see the results of
running your command in a working browser, on-the-spot.
-multiWindow: puts you into a mode where the test web site executes in a separate window, and
selenium supports frames
-forcedBrowserMode <browser>: sets the browser mode (e.g. "*iexplore" for all sessions, no
matter what is passed to getNewBrowserSession
-browserSessionReuse: stops re-initialization and spawning of the browser between tests
-avoidProxy: By default, we proxy every browser request; set this flag to make the browser use our
proxy only for URLs containing '/selenium-server'
-firefoxProfileTemplate <dir>: normally, we generate a fresh empty Firefox profile every time we
launch. You can specify a directory to make us copy your profile directory instead.
-debug: puts you into debug mode, with more trace information and diagnostics
-log: writes lots of debug information out to a log file
-htmlSuite <browser> <startURL> <suiteFile> <resultFile>: Run a single HTML Selenese
(Selenium Core) suite and then exit immediately, using the specified browser (e.g. "*firefox") on the
specified URL (e.g. "http://www.google.com"). You need to specify the absolute path to the HTML
test suite as well as the path to the HTML results file we'll generate.
-proxyInjectionMode: puts you into proxy injection mode, a mode where the selenium server acts
as a proxy server for all content going to the test application. Under this mode, multiple domains can
be visited. For this mode there are several additional flags that are supported: like
i) dontInjectRegex <regex>: an optional regular expression that proxy injection mode can use to
know when to bypass injection
iii) userContentTransformation <regex> <replacement>: a regular expression which is matched
against all test HTML content; the second is a string which will replace matches. These flags can be
used any number of times. A simple example of how this could be useful: if you add "-
userContentTransformation https http" then all "https" strings in the HTML of the test application
will be changed to be "http".
Two other Java system properties are also supported i.e.: -Dhttp.proxyHost and -Dhttp.proxyPort.
Selenium RC normally overrides your proxy server configuration, using the Selenium Server as a
proxy. Use these options if you need to use your own proxy together with the Selenium Server
proxy. Use the proxy settings like this:
java -Dhttp.proxyHost=myproxy.com -Dhttp.proxyPort=1234 -jar selenium-server.jar
If your HTTP proxy requires authentication, you will also need to set -Dhttp.proxyUser and
-Dhttp.proxyPassword, in addition to http.proxyHost and http.proxyPort.
java -Dhttp.proxyHost=myproxy.com -Dhttp.proxyPort=1234 -Dhttp.proxyUser=joe
-Dhttp.proxyPassword=example -jar selenium-server.jar
Why use ProxyInjectionMode?
"Proxy injection" mode is a new highly experimental feature for 0.9.0 Whereas in "normal mode" we
keep two automated test windows--one for Selenium, and one for your application under test
(AUT)--in proxy injection mode we eliminate the separate Selenium window, in favor of "injecting"
Selenium into every HTML page. By injecting ourselves into the HTML, we have increased control
over the AUT. The two experimental "proxy injection mode" browser launchers are:
5. We preferred the proxyInjection mode to start the selenium server.i.e,
java -jar selenium-server. jar –proxyInjectionMode
Once the above settings are done you are done with all the settings that are necessary to write
or run your tests.
You can directly write your tests at the command prompt and run it using any one of the modes. But if
your products or services provides multiple functionalities or you want to develop scripts for different
products and services then you can develop a general framework which allows you to call a base set of
methods whenever you write a new test script or include a new file. Say for example a textbox,
checkbox; radio button is almost used by every application. So a base class can be written to
implement this controls.Similarily for button clicking etc. This framework can act as a wrapper to
the selenium calls.
A Framework is a wrapper or a way of repackaging a function or set of functions (related
or not) to achieve one or more of the following goals (probably incomplete):
• Simplification of use
• Consistency in interface
• Enhancement of core functionality
• Collecting discrete processes into a logical association (an object)
Since our products were add-ons to MSCRM. Our selenium framework contained base classes to
navigate to left nav bar of MSCRM, Selecting a particular work area like workplace, marketing,
services, sales etc., Entities classes for accounts, contacts etc, Control classes for buttons, textboxes,
grid rows, grid columns etc. The lib base class in the framework contained selenium_container
ruby file which contained all the base methods.
Using the Selenium Framework
The framework we built was a wrapper around the Selenium Remote Control. The framework was
written in Ruby and instructions are at the top of this page for installing Ruby. Selenium uses Ruby's
built-in unit testing to create test. It would probably be helpful read up just a little on unit testing in
Ruby before getting started.
The framework handled creating the Selenium test object but the tester was responsible for starting
the Selenium remote control and opening the test page. The Selenium remote control wrapper was
implemented as a Singleton object. Here's a sample of how to get started:
#write ur test scripts here and notes all your test methods should start with test_testname
Clicking Item in MSCRM
MSCRM can be tricky when it comes to clicking "buttons". Sometimes a property must have a
specific value set before you use selenium to try and click a button. Selenium will return a successful
click to the user but nothing will happen. The fact is that Selenium did successfully click the button
but MSCRM ignored the click because the property it was looking for was not set. You will get no
feedback or errors when this happens so it can be very time consuming to fix
Left Nav Menu
The Left Nav Menu is a good example of this clicking problem. Ideally the framework will handle
issues like this but the tester still needs to be aware that this could happen. The left nav item is
enclosed by div element called 'crmNavBar' that has a property called 'SelectedArea'. Before
clicking a button the correct area id must be set for crmNavBar.SelectedArea.id. This is currently
being handled by the LeftNav class in the framework so this should not be an issue.
Selenium and Microsoft CRM
MSCRM uses many frames and Selenium does not really work well with frames. So when using
Selenium you must be sure to drill down into the proper frame. In a nested frame structure to
access a child frame you have to set each parent frame first and then the child frame . The
following is an example of how to select a child frame.
selenium.frame = 'parent'
selenium.frame = 'child'
To clear all frames and start from the parent window use selenium.clear_frames!
There will be a test class in which your test scripts will be written. These scripts will actually run your
tests. While you write your test scripts it is preferred that you use asserts, logging or verify in order
to keep track of your results.
Logging And Using Asserts
When an "assert" fails, the test is aborted.
When a "verify" fails, the test will continue execution, logging the failure.
This allows a single "assert" to ensure that the application is on the correct page, followed by a
bunch of "verify" assertions to test.
If we want to run the complete set of test we can directly execute in from Ruby IDE.But in case we
want to run individual test cases then we need to go the path where selenium framework is present and
then type the command “Ruby filename.rb –name test_testname”.
In case you get error “LoadError: no such file to load — selenium”
This kind of error message can happen if you have installed anything as a gem but you have not
specified require "rubygems" as the first statement in your program or if you have not installed
Or if it is not finding selenium client .So you need to do gem install selenium-client.
One time setup and tear down. This is typically the case for writing selenium tests.You always end up
having a singleton somewhere, upon the first invocation, launches the web application you want to
test, launch the browser, then keep counting how many invocation there are .At each tearDown, you
need to remember to write code to diregister, so that when the count reaches zero, the server will be
shut down and browser closed.
We started with Setup, Test and TearDown + Cleanup. We could clean up any external state of the
system at the end of the test. External state includes, data in database, files on file system, messages
on Ques, etc. But soon we realized that if a test failed, we did not have a way to know what the state
was, when the test failed, coz the AT would clean up the state after its execution. Hence we changed
to a pattern where we did not clean up the state at the end, instead we cleaned it up at the beginning
and setup whatever state the test needed.