Selenium RC vs Selenium WebDriver

Introduction

 

The term “Selenium” is often used interchangeably with “WebDriver”, but they are not the same thing; Selenium is powered by WebDriver. Selenium provides a more robust feature set, and while you can accomplish the same things with WebDriver, Selenium takes care of the details for some of the more complex operations.

 

RemoteWebDriver interacts with the Grid to run tests across multiple machines or VMs. In other words, you write your tests with the RemoteWebDriver (or with Selenium 2), and then you can plug them into the grid

 

Grid 2 is the new version of Grid, which works with the new WebDriver-Backed Selenium (Selenium 2).

 

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.

 

  • Selenium Core – more a component of selenium than a stand alone project. Without going into the project history, Selenium was once just a collection of .js files that automated a browser. No one uses these directly, they’re just there for legacy reasons.

 

  • Selenium IDE – a firefox plugin for record/playback. You may want to start with this, to get used to the api, but you’ll outgrow it soon

 

  • Selenium RC and when you do outgrow it, you’ll use Selenium Remote Control. Selenium 1.x is a client-server architecture. You use the RC libraries to program tests that communicate with the server, and the server relays those commands to a browser.

 

  • Selenium Grid – a way to run Selenium testing on a distributed network of computers. Good for speeding things up once you’ve got a lot of tests.

 

  • Cubic Test – An eclipse-based tool that leverages selenium for testing. Not sure how popular it is.

 

  • Bromine – a web based script and test management tool. Uses selenium RC to run tests.

 

 

WebDriver

 

Then we get to the Selenium 2. Selenium 2 is a major departure from the Selenium 1 model because it doesn’t require a Selenium server. I say ‘require‘ because it’s optional to run the tests remotely on another computer. Selenium Server Standalone is the server you’d use for this. It’s compatible with Selenium-RC as well as Selenium 2 for remote purposes.

 

You may have seen Selenium 2 referred to as WebDriver. WebDriver was another project that was merged a couple years ago and became the basis for Selenium 2. That’s why Selenium 2 has a WebDriver interface, sometimes called the “WebDriver” api to distinguish from Selenium-RC.

 

If you’re just starting out, I’d take a look at Selenium 2. It’s getting 99.9% of the developer love right now, and the Selenium 1.x api’s won’t be advancing any further. The Java libraries are the best supported, followed closely by .Net and Python/Ruby. Watir (the popular Ruby browser automation library) uses selenium under the hood if you want another api option.

 

 

Selenium Benefits over WebDriver

 

  • Supports many browsers and many languages, WebDriver needs native implementations for each new language/browser combo.
  • Very mature and complete API
  • Currently supports JavaScript alerts and confirms better

 

 

Benefits of WebDriver Compared to Selenium

 

  • Native automation faster and a little less prone to error and browser configuration
  • Does not Requires Selenium-RC Server to be running
  • Access to headless HTML Unit can allow really fast tests
  • Great API

 

By Ruchi Singh

 

Adactin Group