Selenium is a portable software-testing framework for web applications. Selenium provides a playback (formerly also recording) tool for authoring tests without the need to learn a test scripting language (Selenium IDE). It also provides C #, Groovy, Java, Perl, PHP, Python, Ruby and Scala. The most modern web browsers. Selenium deploys on Windows, Linux, and macOS platforms. It is open-source software, released under the Apache 2.0 license: web developers can download and use it without charge.
Selenium was originally developed by Jason Huggins in 2004 as an internal tool at ThoughtWorks. Huggins was joined by other programmers and testers at ThoughtWorks, before Paul Hammant joined the team and steered the development of the second mode of operation that would later become “Selenium Remote Control” (RC). The tool was open sourced that year. In 2005 Dan Fabulich and Nelson Sproul (with help from Pat Lightbody) made an offer to accept a series of patches that would transform Selenium-RC into what it became best known for. In the same meeting, the steering of Selenium as a project continues as a committee, with Huggins and Hammer being the ThoughtWorks representatives. In 2007, Huggins joined Google. Together with others like Jennifer Bevan, he continued with the development and stabilization of Selenium RC. At the same time, Simon Stewart at ThoughtWorks developed a superior browser automation tool called WebDriver. In 2009, after a meeting between the developers and the Google Test Automation Conference, it was decided to merge the two projects, and call the new project Selenium WebDriver, or Selenium 2.0. In 2008, Philippe Hanrigou (then “ThoughtWorks”) made “Selenium Grid”, which provides a multiple selection of local or remote systems, thus minimizing test execution time. Open source, a similar capability to the internal / private cloud for Selenium RC. Pat Lightbody had already made a private cloud for “HostedQA” which he went to Gomez, Inc.The name Selenium 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.
Selenium is composed of several components with a specific role in the development of web application test automation.
Selenium IDE is a complete integrated development environment (IDE) for Selenium tests. It is implemented as a Firefox Add-On and available on Chrome Store recently, and includes recording, editing, and debugging tests. Selenium Recorder. Selenium-IDE was originally created by Shinya Kasatani and donated to the Selenium project in 2006. It is little-maintained and is compatible with Selenium RC, which was deprecated. Scripts can be automatically recorded and edited. Scripts are recorded in Selenese, a special test scripting language for Selenium. Selenese provides commands for performing actions in a browser (click to link, select an option), and for retrieving data from the resulting pages. The 2. x version of the Selenium IDE for Firefox stopped working after the Firefox 55. Selenium IDE 3.x. But users can run the older Selenium IDE on some older Firefox versions (pre-Firefox 55) or try other alternative solutions
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 APIs for Java, C #, Ruby, JavaScript 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.
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, which sends commands to a browser and retrieves results. Most browser drivers actually launch and access a browser application (such as Firefox, Chrome, Internet Explorer, Safari, or Microsoft Edge); There is also an HtmlUnit browser driver, which simulates a browser using the headless browser HtmlUnit. Unlike in Selenium 1, Selenium WebDriver does not require a special server to run 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). Where possible, WebDriver uses browser-based functionality rather than browser-based JavaScript. This bypasses problems with subtle differences between native and JavaScript commands, including security restrictions. In practice, this means that the Selenium 2.0 API has significantly fewer calls than the Selenium 1.0 API. Where Selenium 1.0 is used to provide a rich interface for many different browser operations, Selenium 2.0 is designed to provide a framework for building up a specific domain. 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. As of early 2012, Simon Stewart (inventor of WebDriver), who was then with Facebook, and David Burns of Mozilla were negotiating with the W3C to make WebDriver a standard Internet. In July 2012, the working draft was released. Selenium-Webdriver (Selenium 2.0) is fully implemented and supported in Python, Ruby, Java, and C #.
Selenium Remote Control (RC) is a server, written in Java, which accepts commands for the browser via HTTP. It 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, the Selenium project currently provides for PHP, Python, Ruby, .NET, Perl and Java. The Java driver can also be used with JavaScript (via the Rhino engine). An instance of selenium RC server is needed to launch html test case – which means that the port should be different for each parallel run. However, for Java / PHP test case only one Selenium RC instance needs to be running continuously. 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 for the browser in question, from the test language of Java, .Net, Python or Ruby. The wire protocol (called ‘Selenese’ in its day) was reimplemented in each language port. After the refactor by Dan Fabulich and Nelson Sproul (with the help of Pat Lightbody) there was an intermediate daemon between the driving test script, and the browser. The benefits included the ability to drive remote browsers, and the reduced need to increase the number 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 had been known as Comet.
Selenium Grid is a server that runs 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 WebDriver nodes, and lets tests use these instances. Selenium Grid allows running tests in parallel on multiple machines, and to manage different browser versions and browser configurations centrally (instead of in each individual test). The ability to run tests on remote browsers is useful for testing the load of multiple machines, and for running tests in browsers running on different platforms or operating systems. The latter is particularly useful in cases where it can not be used for testing.