[edit]History
The name comes from a joke made by Huggins in an email, mocking a competitor named
Mercury, saying that you can cure mercury poisoning by taking Selenium supplements. The others that received the email took the name and ran with it.
[2]
The latest side project is Selenium Grid, which provides a hub allowing the running of multiple Selenium tests concurrently on any number of local or remote systems, thus minimizing test execution time.
[edit]Selenium components
[edit]Selenium IDE
Selenium IDE is a complete
integrated development environment (IDE) for Selenium tests. It is implemented as a
Firefox extension, and allows recording, editing, and debugging tests. It was previously known as Selenium Recorder.
Selenium-IDE was originally created by Shinya Kasatani and donated to the Selenium project in 2006.
[citation needed]
Scripts may be automatically recorded and edited manually providing
autocompletion support and the ability to move commands around quickly.
Scripts are recorded in Selenese, a special test scripting language for Selenium. Selenese provides commands for performing actions in a browser (click a link, select an option), and for retrieving data from the resulting pages.
Features:
- Easy record and playback
- Intelligent field selection will use IDs, names, or XPath as needed
- Autocomplete for all common Selenium commands
- Walk through tests
- Debug and set breakpoints
- Save tests as Selenese, Ruby scripts, or other formats
- Support for Selenium user-extensions.js file
- Option to automatically assert the title of every page
- Easy customization through plugins
[edit]Selenium Client API
As an alternative to writing tests in Selenese, tests can also be written in various programming languages. These tests then communicate with Selenium by calling methods in the Selenium Client API. Selenium currently provides client APIs for Java, C#, Ruby and Python.
With Selenium 2, a new Client API was introduced (with WebDriver as its central component). However, the old API (using class Selenium) is still supported.
[edit]Selenium Remote Control
Selenium Remote Control (
RC) is a server, written in
Java, that accepts commands for the browser via
HTTP. RC makes it possible to write automated tests for a web application in any programming language, which allows for better integration of Selenium in existing unit test frameworks. To make writing tests easier, Selenium project currently provides client drivers for
PHP,
Python,
Ruby,
.NET,
Perl and
Java. The Java driver can also be used with
JavaScript (via the
Rhino engine). A new instance of selenium RC server is needed to launch html test case - which means that the port should be different for each parallel run.
[citation needed] However for Java/PHP test case only one Selenium RC instance needs to be running continuously.
[citation needed]
Selenium Remote Control was a refactoring of
Driven Selenium or
Selenium B designed by Paul Hammant, credited with Jason as co-creator of Selenium. The original version directly launched a process for the browser in question, from the test language of Java, .Net, Python or Ruby. The wire protocol (confusingly called 'Selenese' in its day) was reimplemented in each language port. After the refactor by Dan Fabulich, and Nelson Sproul (with help from Pat Lightbody) there was an intermediate daemon process between the driving test script, and the browser. The benefits included the ability to drive remote browsers, and the reduced need to port every line of code to an increasingly growing set of languages.
Selenium Remote Control completely took over from the
Driven Selenium code-line in 2006. The browser pattern for 'Driven'/'B' and 'RC' was response/request, which subsequently became known as
Comet.
With the release of Selenium 2, Selenium RC has been officially deprecated in favor of Selenium WebDriver.
[edit]Selenium WebDriver
Selenium WebDriver is the successor to Selenium RC. Selenium WebDriver accepts commands (sent in Selenese, or via a Client API) and sends them to a browser. This is implemented through a browser-specific
browser driver, which sends commands to a browser, and retrieves results. Most browser drivers actually launch and access a browser application (such as Firefox or Internet Explorer); there is also a
HtmlUnit browser driver, which simulates a browser using HtmlUnit.
Unlike in Selenium 1, where the Selenium RC server was necessary to run tests, Selenium WebDriver does not need a special server to execute tests. Instead, the WebDriver directly starts a browser instance and controls it. However, Selenium Grid can be used with WebDriver to execute tests on remote systems (see below).
As of early 2012, Simon Stewart of Google (inventor of WebDriver) and David Burns of Mozilla are negotiating with the
W3C to make WebDriver an internet standard. As such, Selenium-Webdriver (Selenium 2.0) aims to be the reference implementation of the WebDriver standard in various programming languages. Currently Selenium-WebDriver is fully implemented and supported in Python, Ruby, Java, and C#.
In practice, this means that the Selenium 2.0 API has significantly fewer calls than does the Selenium 1.0 API. Where Selenium 1.0 attempted to provide a rich interface for many different browser operations, Selenium 2.0 aims to provide a basic set of building blocks from which developers can create their own
Domain Specific Language. One such DSL already exists: the
Watir project in the Ruby language has a rich history of good design. Watir-webdriver implements the Watir API as a wrapper for Selenium-Webdriver in Ruby. Watir-webdriver is created entirely automatically, based on the WebDriver specification and the HTML specification.
[edit]Selenium Grid
Selenium Grid is a server that allows tests to use web browser instances running on remote machines. With Selenium Grid, one server acts as the hub. Tests contact the hub to obtain access to browser instances. The hub has a list of servers that provide access to browser instances (WebDriver nodes), and lets tests use these instances. Selenium Grid allows to run tests in parallel on multiple machines, and to manage different browser versions and browser configurations centrally (instead of in each individual test).