Selenium is a test automation tool
that automates browsers. Selenium grid
is built on the traditional set up of Selenium. It takes advantage of the
following properties.
- The Selenium test, the application under test and the remote
control/browser pair can communicate through HTTP, so they do not need to be
collocated.
- The Selenium RC and the browser are never tied up to a
specific application and hence, they can
be easily shared through multiple applications and multiple projects.
The Selenium Grid transparently
distributes tests across multiple physical and virtual locations so that they
can be run in parallel. This speeds up the testing process, giving back quick
and accurate feedback. Through Selenium Grid, the existing computer
infrastructure can be leveraged. It enables running multiple tests in parallel,
on multiple nodes/clients in a heterogenous environment of OS and browser
support.
The Selenium Grid allows running of
multiple parallel instances of WebDriver or Selenium RC. It makes all nodes
appear as a single instance and so the tests do not need to understand the
actual infrastructure. To run the grid the Selenium Server Standalone package
includes
- The Hub
- The Web Driver
- The Selenium RC
The Selenium exposes an external
interface similar to the traditional Remote Control. It acts like a central
point which receives the entire test request and distributes it to the right
nodes. It is responsible for
- Allocating a selenium RC to a specific test
- Limiting the number of concurrent test runs on each Remote
Control
- Shielding the tests from the actual grid infrastructure.
Testing Practices with Selenium Grid
- Download the latest Selenium Server standalone JAR file.
Here we are referring to version 2.25.0
- Use the following command to launch the Selenium Server. It
will start the Selenium Server Hub role.
- java -jar selenium-server-standalone-2.25.0.jar -port 4444
-role hub -nodeTimeout 600
- On launching Selenium Standalone in the Hub role, it starts
listening to nodes and Seleniumtesting. By default, the Hub provides 5 sessions on the server.
- For running the tests with Selenium Grid, the Selenium
WebDriver tests use the class instances
of RemoteWebDriver and DesiredCapabilites in order to define the browser,
version and platform in which the tests will be executed on. Based on the preferences
in the DesiredCapabilities, the Hub will redirect the test to the node matching
the preferences.
These preferences are set using the methods of
DesiredCapabilities class. They are
- setBrowserName()
- setVersion()
- setPlatform()
In order to refine the number of
available browsers, an additional browser parameter can be specified. This can
also be used for specifying more than one browser as well.
The command will look like this:
java -jar
selenium-server-standalone-2.42.0.jar -role node -browser browserName=safari
-browser browserName=chrome -browser browserName=firefox -hub http://localhost:4444/grid/register
For setting up Selenium Grid to work
with Internet Explorer or Chrome, additional configuration may be required for
each. It is recommended to check out the browser driver documentation for this.
When using Selenium Grid, confusions
can occur from time to time. Using Selenium Extras helps to clear these
confusions and helps to fix issues which come up outside of the web browser.
Some of its cleanup tasks are:
- After a complete test run it kills any remaining or crashed
instances of the browser used.
- It modifies he browser settings on launch for a hassle free
test execution.
- It periodically starts grid nodes to clear up memory leaks.
- It automatically records a video of the running test session
at the OS level which helps to review the test failure more effectively.
Furthermore, restarting the whole OS
after a certain amount of test runs allows to clear up any remaining crashed
items. Restarting the entire machine after every 10 to 20 test runs gives a
huge boost in stability.
Conclusion
The main advantage of Selenium Grid
is to be able to run tests in parallel. It is to be noted that Selenium Grid
does not by itself provide for parallelization.
It can handle multiple
connections, but the tester will need to find a way to set up and execute the
tests in parallel. Some notable approaches include testing
through a framework (TestNG in Java), testing through Continuous Integration or
testing through third party library.