Selenium Grid

An efficient development cycle requires prompt and reliable feedback. Stop waiting hours to get the results of your web acceptance builds! Selenium Grid transparently distribute your tests on multiple machines so that you can run your tests in parallel, cutting down the time required for running in-browser test suites. This will dramatically speeds up in-browser web testing, giving you quick and accurate feedback you can rely on to improve your web application.

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.