Setting up and maintaining your own Selenium Grid


In this article we’ll focus on setting up your own Selenium grid from scratch.
A Selenium grid is a collection of browser nodes that are available for automated testing.
We’ll show you how to set up a Selenium Grid Master (or Hub, or Selenium Server, whichever you want to call it) and how to connect various Selenium Nodes to the grid.

Selenium Hub/Master/Server

The Hub is responsible for (amongst other things):
– keeping track of the nodes in the grid
– forward your tests to available Selenium nodes

A Selenium-Grid is very useful to run one or multiple tests simultaneously across several browsers in parallel. This means you can really shorten your total test-run time, resulting in shorter release-cycles as well.
To set up a grid, we need to start with setting up a hub.

What we recommend is creating a new Linux Virtual Machine and making sure it’s properly set up (Java installed, internal network configured, …).
You need to make sure you have Java installed, as Selenium comes in a .jar file format.
Go ahead and download Selenium.

You should now have a selenium-server-standalone.jar file. To start the hub, open up your Terminal window and type:

java -jar selenium-server-standalone-2.52.0.jar -role hub

You should see “INFO – Launching Selenium Grid hub”, this means the Hub is running correctly.
As a Hub, it will listen on port 4444 on your local computer. This port is where the other Selenium nodes will have to connect to, to register themselves to the Selenium Hub and be part of the grid.

Setting up a Selenium Node

Now we’ll add our first node to the grid. We suggest you create a new VM and provision the VM with the browsers you want to run tests on.

Let’s say you want to run your tests on both IE11 and Microsoft Edge.
You can make a choice between the free Windows Developer OS Images which come equipped with browsers ranging from IE6 to Microsoft Edge.

Once you’ve set up the VM to your liking (configure network, install the browsers, enable the ’empty-cache-on-exit’, install silverlight/flash, installed all updates, …) you’re ready to register to the Selenium grid.

You need to use the same selenium-server-standalone jar but this time the command looks different:

java -jar selenium-server-standalone-2.52.0.jar -role node -hub http://localhost:4444/grid/register

The important parts are “-role node” and “-hub …”. The role indicates to the Selenium Jar that we want to run this as a Selenium Node. The “-hub” specifies the Hub where the jar needs to connect to, to register itself.

Since you are running this on a VM, the localhost part needs to change to the internal IP of the machine running your Hub. Go back to the VM running your hub and check what its internal ip is. In most of the cases, this should be something like 10.x.x.x or 192.x.x.x

If everything went ok, you should now have your Selenium node connected to the grid. The log output from the Hub should indicate that the node registered successfully.

Improving the Selenium Node

Let’s say you also want to have a video of your test run, so that you can later go back and see what happened during any specific test.

To accomplish this, we suggest to install a VNC server on your VM. With a VNC server, you can connect to the VM and interact with mouse/keyboard, but you can also use an utility called flvrec to record the VNC output stream to a FLV file.

Since we want to have a video of very single test session, we need to figure out how to start and stop recording for every test.

One thing we can do is set up a wrapper app, which will first start the recording, then launch the browser and once the browser closed stop the recording.

An example on how to do this with a Linux node:

mv /usr/bin/chrome /usr/bin/chrome_original

PID=$(flvrec -o ~/test.flv localhost:0)
kill $PID

The way TestingBot does this is by having a NodeJS proxy intercept the start/stop command before it reaches the Selenium Node. This way we have a clean way to start/stop a video, without using a wrapper approach.

Run a test on the Selenium Grid

Now that our Selenium Grid is set up and we have one or more nodes connected to the hub, we can run our first Selenium browser test.

Let’s say for example that you registered a Selenium Node with IE11 to the grid. To run a test on IE11, we’ll create a test that requests IE11 from the hub. The hub will automatically forward the test to the correct node and our test will run on that specific node.

require "rubygems"
require "selenium-webdriver"
require "selenium/client"

caps = {
:browserName => "internet explorer",
:version => "11"

urlhub = "http://[IP_OF_THE_HUB_VM]/wd/hub"
client =
client.timeout = 220

@webdriver = Selenium::WebDriver.for :remote, :url => urlhub, :desired_capabilities => caps, :http_client => client
@webdriver.manage.timeouts.implicit_wait = 10 # seconds ""
puts @webdriver.title
@webdriver.save_screenshot "google.png"

Don’t forget to change the IP_OF_THE_HUB_VM with the correct internal ip of your hub VM.
Ready to start your first? After you’ve run this test, you will see that the test has printed “Google” and has taken a screenshot of the Google homepage.

This test will have completed running on your IE11 VM. If everything went well, a video of the test should be available on that VM as well.

Hybrid Selenium Grid

We’ve open-sourced our Selenium grid, coded in NodeJS.

It behaves the same like the example above and has been running in production at TestingBot for over 4 years now.

The additional advantage of node-seleniumgrid is that you can configure it to run tests on our Selenium grid and on your local grid.

Suppose you created a Grid with your IE6-IE11 nodes but also want to run tests on Edge.
With node-seleniumgrid you just point your tests to the hub, if the test requests a combination that’s available on your local grid then it will use the local grid. If your test wants to run a browser that’s not available on your grid, it will forward the request to TestingBot to run the test on our grid of 500+ browser combinations.

DIY or use TestingBot?

We’ve demonstrated the minimum required to set up a Selenium Grid.

Now let’s say you want to run your tests in parallel, on different browser combinations and you want to be ensured that no test data from a previous test is left behind, and want a video of the test run, don’t want to maintain the VMs with updates and patches, and all other best practices… It takes a lot of time to accomplish all these things, we’ve learned a lot in the last 5 years maintaining our huge Selenium Grid.

With TestingBot, you no longer have to worry about:

– Updating/Patching VMs
– Installing new browser versions
– Leftover testdata, browsers that didn’t get closed from the previous run, …
TestingBot guarantees a new pristine VM for every single test run.
– Network/connectivity issues
– Screenshots/videos/logs
– VMs/Hypervisors/Instabilities

Take advantage of our knowledge and infrastructure and run your tests on our Grid, we take care of everything so that you can only focus on what it is you want to do: create and run tests.

Start your free trial now.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *