Selenium Course
- 64k Enrolled Learners
- Weekend/Weekday
- Live Class
(23100)
A well-known brand in the test automation space is Selenium. But not everybody knows what its different parts are and how they changed over time. A key element in the early phases of Selenium’s development was the Selenium Remote Control (RC). However, is Selenium RC still applicable today? What is the difference between Selenium RC vs WebDriver?
As we examine Selenium RC through a practical use case, let’s examine what it is and how it varies from Selenium WebDriver.
Real-World Example: Automating a Legacy Travel Booking Site Fast
This was in the year 2012 when a QA engineer was in action at a travel company. The company’s booking platform works on older technologies such as HTML and JavaScript. In the past, whenever the team had to automate browser tests involving many browsers and OS combinations, they resorted to using the Selenium RC to recreate user actions applying including logging in, filling out forms, selecting dates on calendars, and filtering fares on the booking website.
Selenium RC worked as a middleman between the test script and the browser, sending commands to the server, which would mimic the actions that the browser would have actually executed. Moving forward, as the system continued to newer frameworks needing even more upper hand and speed, they went on to utilize Selenium WebDriver, allowing direct communication from the tests into the browsers, skipping the server.
What do you mean by Selenium RC?
Selenium RC (Remote Control) must be considered as one of the earlier components of the Selenium suite for automating web applications. It was created mainly to circumvent the same-origin policy restrictions governing browser security, which restricted JavaScript code from pulling content on a different domain other than that given for the web page itself.
Selenium RC comprises:
- A Selenium Server that provided a proxying facility between the test scripts and the browser.
- Multiple client libraries are written in other programming languages such as Java, C#, Perl, and Python.
- Test scripts would send commands to the RC server, which converted them into JavaScript instructions run within the browser. This was meant to support cross-browser testing, and it had a foothold as a big issue back in the early 2000s.
Selenium RC vs Selenium WebDriver: Key Differences
| Feature | Selenium RC | Selenium WebDriver |
| Architecture | Uses a Selenium Server as a middle layer to inject JavaScript into browsers. Commands are routed through the server before reaching the browser. | Interacts directly with the browser’s native API using browser-specific drivers like ChromeDriver, GeckoDriver, etc. |
| Speed & Performance | Slower due to the overhead of server communication and JavaScript injection. | Faster, as it eliminates the need for a server and communicates directly with the browser. |
| Browser Control | Indirect. Executes scripts inside the browser via JavaScript, often facing security restrictions (same-origin policy). | Direct. Uses the browser’s native support to perform actions like clicking, typing, or navigating. |
| Same-Origin Policy Handling | Required workarounds to bypass browser restrictions. | No such limitations. Works seamlessly with modern web applications. |
| API Simplicity | Verbose and harder to read. Requires starting and stopping the server manually. | Clean, concise, and more object-oriented. Methods are more intuitive and map closely to user actions. |
| Browser Compatibility | Limited compatibility with modern browsers. No longer updated. | Supports all modern browsers: Chrome, Firefox, Safari, Edge, Opera, etc. Actively updated. |
| Support for Advanced UI Interactions | Very basic. Limited interaction with dynamic content like AJAX and pop-ups. | Rich support for advanced interactions such as drag-and-drop, sliders, keyboard events, file uploads, etc. |
| Installation Requirements | Requires downloading and configuring the Selenium RC Server separately. | No need for a central server. Just the WebDriver and the appropriate browser driver (e.g., ChromeDriver). |
| Testing Framework Integration | Works with older testing frameworks, but setup is complex. | Easily integrates with popular frameworks like TestNG, JUnit (Java), NUnit (C#), PyTest (Python), etc. |
| Language Support | Supports Java, C#, Perl, PHP, Python, and Ruby. | Supports the same languages, but with more active development and libraries. |
| Community Support & Maintenance | Deprecated. No longer maintained since Selenium 2. | Actively maintained. New features, fixes, and documentation are regularly updated. |
| Mobile Testing Support | Not supported. | Can be used with tools like Appium for mobile testing. |
| Headless Browser Support | Not supported. | Fully supported (e.g., Chrome headless, Firefox headless). Great for CI/CD environments. |
| Cloud & Grid Compatibility | Can be used with Selenium Grid but is less flexible. | Full support for Selenium Grid, BrowserStack, Sauce Labs, etc., enabling scalable cloud testing. |
Why Selenium RC Is Deprecated?
Due to a number of significant drawbacks and the development of superior substitutes, chief among them Selenium WebDriver, Selenium RC (Remote Control) has been deprecated. The following explains why Selenium RC is no longer advised:
1. More Complex Architecture and Slower Performance
Selenium RC required the use of a separate Selenium Server that served as a proxy between the test script and the browser. This added to:
- Setup complexity.
- HTTP requests and JavaScript injection cause performance overhead.
- Indirect control of browser operations which increased the time required to run tests and the difficulty in debugging them.
2. Security Incompatibility
- Selenium RC worked by injecting JavaScript into browsers, which clashed with the same-origin policy problems, limiting interaction with web apps of domains other than its own.
- Therefore, it sustained incompatibilities with modern browsers and changing web standards.
- Web applications with AJAX, dynamic content, and modern features of the browser could not be reliably tested.
3. Webdriver is Superior.
- Directly controls the browser via a driver unique to that browser (like ChromeDriver).
- Faster, reliable, has advanced UI interaction methods, headless testing, and mobile automation support.
- This became the heart of Selenium 2 and later, with a stronger architecture, completely replacing RC.
Benefits of Using Selenium WebDriver
- Direct communication with a browser without extra intermediary servers
- Support for newer technologies such as HTML5 and AJAX
- Support for integration with different testing frameworks like TestNG, JUnit, and NUnit
- A better community behind it, with a lot of documentation
- It supports working with headless browsers and cloud-based platforms like BrowserStack and Sauce Labs.
At what point would you still come across Selenium RC?
- Selenium RC is rarely used in contemporary development unless:
- Legacy test cases that were created more than ten years ago are being maintained by you.
- Old codebases are being analyzed or migrated by you.
- You’re studying the evolution of automation tools for educational purposes.
