selenium remote control vs webdriver

Question

I'm not sure I quite understand the difference. WebDriver API also directly controls the browser of choice. When should you use selenium remote control (selenium RC) instead ?

Right now my current situation is I am testing a web application by writing a suite with Selenium WebDriver API and letting it run on my computer. The tests are getting longer and longer to complete, so I have been searching for ways to run the tests on a linux server.

If I use sleneium remote control, does this mean I have to rewrite everything I wrote with WebDriver API ?

I am getting confused with Selenium Grid, Hudson, Selenium RC. I found a selenium grid plugin for Hudson, but not sure if this includes Selenium RC.

Am I taking the correct route ? I envision the following architecture:

Hudson running on few ubuntu dedicated servers.
Hudson running with xvnc & selenium grid plugin. (Do I need to install firefox separately ?)
Selenium grid running selenium RC test suites.

I think this is far more time efficient than running test on my current working desktop computer with WebDriver API.

Answer 1

As far as I understand, Webdriver implementation started little later than Selenium RC. From my point of view, WebDriver is more flexible solution, which fixed some annoying problems of SeleniumRC.

WebDriver provides standard interface for testing web GUI. There are several implementations of this interface (HTTP, browser-specific and based on Selenium). Since you already have some WebDriver tests, you must be familiar with basic docs like this

The tests are getting longer and longer to complete, so I have been searching for ways to run the tests on a linux server.

Did you try to find actual bottlenecks? I'm not sure, that elimination of WebDriver layer will help. I think, most time is spent on Selenium commands sending and HTTP requests to system-under-test.

If I use sleneium remote control, does this mean I have to rewrite everything I wrote with WebDriver API ?

Generally, yes. If you did not implement some additional layer between tests code and WebDriver.

As for Selenium Grid: You may start several Selenium RC instances on several different [virtual] nodes, then register them in Selenium Grid. Your tests connect to Selenium Grid, and it redirects all commands to SeleniumRC instances, coordinating them in accordance with required browsers.

For details of hudson plugin you may find more info here

Answer 2

WebDriver is now Selenium 2. The Selenium and WebDriver code bases are being merged. WebDriver gets over a number of issues that Selenium has and Selenium gets over a number of issues that Webdriver has.

If you have written your tests in Selenium one you don't have to rewrite them to work with Selenium 2. We, the core developers, have written it so that you create a browser instance and inject that into Selenium and your Selenium 1 tests will work in Selenium 2. I have put an example below for you.

// You may use any WebDriver implementation. Firefox is used here as an example
WebDriver driver = new FirefoxDriver();

// A "base url", used by selenium to resolve relative URLs
String baseUrl = "http://www.google.com";

// Create the Selenium implementation
Selenium selenium = new WebDriverBackedSelenium(driver, baseUrl);

// Perform actions with selenium
selenium.open("http://www.google.com");
selenium.type("name=q", "cheese");
selenium.click("name=btnG");

Selenium 2 unfortunately has not been put into Selenium 2 but it shouldn't be too long until it has been added since we are hoping to reach beta in the next couple of months.