How it Works

To understand Selenium Grid you first need to understand how the standard Selenium web testing tool works.

Traditional Selenium Setup

To understand Selenium Grid you first need to understand how the standard Selenium web testing tool works.

Fundamentally, Selenium is a tool that let you programmatically launch a browser, drive the browser (open a url, enter some data, click on a link) and check the browser state (a section is visible, specific text is present, a widget is disabled). It is the tool of choice for automating web testing.

You drive the key piece in charge of controlling the browser, the Selenium Remote Control, by sending HTTP requests following a specific protocol (called Selenese). Therefore, basically all that a Selenium test does, is to target a specific Selenium Remote Control and to send it HTTP requests (through a higher level client API).

This setup works great for a few tests, but as your test suite starts getting bigger, its limitations become clearer:

• The Selenium remote control is quite slow at driving the browser. Therefore, unless your application or your network is especially slow, the remote control/browser pair will end up being the bottleneck of your test suite.
• You can only run a limited number of concurrent tests on the same remote control before seriously impacting its stability. Practically speaking, launching more than 6 browsers on the same Selenium Remote Control is not advisable. The limitations are even more drastic for Internet Explorer.
• Your tests can target multiple Selenium Remote Controls to work around the limitation on the number of parallel tests that you can run on a single remote control. Nevertheless that does not scale very well. It can easily be done at the continuous integration build level (one for Internet Explorer, one for Firefox, one for Safari). However, allocating a Selenium Remote Control to a specific test quickly becomes a nightmare if you want to run your selenium tests in a highly parallelized fashion. Your tests also become way too aware of the Selenium Remote Control infrastructure, which makes it difficult to evolve your infrastructure transparently.

Due to all these limitations, Selenium tests typically run in sequence or are only mildly parallelized. That makes for test suites that take from half an hour to multiple hours to run. Not ideal, especially if you strive for Agile processes emphasizing a quick feedback loop.

Selenium Grid Setup

Selenium Grid builds on the traditional Selenium setup, taking advantage of the following properties:

• The Selenium test, the application under test, and the remote control/browser pair do not have to be co-located. They communicate through HTTP, so they can all live on different machines.
• The Selenium tests and the web application under test are obviously specific to a particular project. Nevertheless, neither the Selenium remote control nor the browser is tied to a specific application. As a matter of fact, they provide a capacity that can easily be shared by multiple applications and multiple projects.

Consequently, if only we could build a distributed grid of Selenium Remote Controls, we could easily share it across builds, applications, projects - even potentially across organizations. Of course we would also need to address the scalability issues as described earlier when covering the traditional Selenium setup. This is why we need a component in charge of:

• Allocating a Selenium Remote Control to a specific test (transparently)
• Limiting the number of concurrent test runs on each Remote Control
• Shielding the tests from the actual grid infrastructure

Selenium Grid calls this component the Selenium Hub.

• The Hub exposes an external interface that is exactly the same as the one of a traditional Remote Control. This means that a test suite can transparently target a regular Remote Control or a Selenium Hub with no code change. It just needs to target a different IP address. This is important as it shields the tests from the grid infrastructure (which you can scale transparently). This also makes the developer’s life easier. The same test can be run locally on a developer machine, or run on a heavy duty distributed grid as part of a build – without ever changing a line of code.
• The Hub allocates Selenium Remote Controls to each test. The Hub is also in charge of routing the Selenese requests from the tests to the appropriate Remote Control as well as keeping track of testing sessions.
• When a new test starts, the Hub puts its first request on hold if there is no available Remote Control in the grid providing the appropriate capabilities. As soon as a suitable Remote Control becomes available, the Hub will serve the request. For the whole time, the tests do not have to be aware of what is happening within the grid; it is just waiting for an HTTP response to come back.

Of course to really take advantage of the Selenium Grid, you need to run your tests in parallel. If you are writing your Selenium tests in Java, you can leverage TestNG parallel runs or Parallel JUnit. If you prefer to write your Selenium tests in Ruby, you might want to look into DeepTest or spawn multiple processes. Chances are that your favorite programming language and development platform already have a solution.

Requesting a Specific Environment

A traditional Selenium test requests a specific browser at the beginning of every Selenium session. It requests it in the form of a pre-defined string such as *firefox or *iexplore. Nevertheless a test cannot request more fine grained capabilities such as Firefox on Linux or IE 6.0 on Windows XP SP2. The underlying assumption is that you are targeting a single Remote Control, so you should be aware if it runs on Windows XP or not.

If you want, you can operate a Selenium Grid in the exact same way. It might very well be all that you need. However the more heterogeneous your grid becomes, the more you will want to make sure that a specific build runs on Firefox on Windows and only on Firefox on Windows. This makes troubleshooting test failures considerably easier. It might also be that you have a handful of tests that are specifically targeting this nasty bug for this particular browser on this particular platform.

Either way, you can make a Selenium Grid aware of the environments you care about. The Selenium Hub will then ensure that a test runs only on the Selenium Remote Controls providing the requested environment.

The way it works is that Selenium Grid instruments the traditional Selenium Remote Controls so that they register themselves to the Hub when they start. When they do so they can also describe which environment they are providing, suppose Firefox on Windows.

At this point, if you want to target a test to a specific environment, all you have to do is to substitute the traditional browser string (say *firefox) with the name of the environment (say Firefox on Windows). If you write your test in Java change:

new DefaultSelenium("localhost", 4444, **'*firefox'**, 'http://amazon.com');

into:

new DefaultSelenium("localhost", 4444, **'Firefox on Windows'**, 'http://amazon.com');

That will do the trick.

It is important to note that the names of the environments are completely arbitrary. You are in control and can choose the ones that make sense for you. You are also not restricted to the browser / platform paradigm. You can define environments such as “IE 7 on Chinese locale” or “Firefox on Quadri-processor” if that makes sense in your testing environment.

To define you own environments, edit the grid_configuration.yml file at the root of the Selenium Grid binary distribution.