What is Selenium?
Selenium is an open-source tool that automates web browsers. It provides one interface that allows you to write test scripts in programming languages like Ruby, Java, NodeJS, PHP, Perl, Python, and C#, among others, you can start learning this with Selenium Training in Pune.
A browser-driver then executes these scripts on a browser-instance on your device (more on this in an exceedingly moment).
Note: to induce started with Selenium's latest version (WebDriver-based implementation), you will only need one selenium jar file (selenium-standalone-server-''.jar) to run tests both locally and on remote devices. This JAR file contains W3C-standard WebDriver API and Selenium Grid, together with Selenium Server (for existing users of deprecated Selenium RC implementation).
Here’s how those components work:
Selenium WebDriver
Also referred to as Selenium 2.0, WebDriver executes test scripts through browser-specific drivers. It consists of:
API
Application Programming Interface. Ports test scripts you write in Ruby, Java, Python, or C# to Selenese (Selenium’s own scripting language), through bindings.
Library
Houses the API and language-specific bindings. Although many third-party bindings exist to support different programming languages, the core client-side bindings supported by the most project are Selenium Java (as selenium jar files), Selenium Ruby, Selenium dotnet (or Selenium C#, available as .dll files), Selenium Python, and Selenium JavaScript (Node).
Driver
An executable module that reveals a browser instance and runs the test script. Browser-specific—for instance, Google develops and maintains Chromedriver for Selenium to support automation on Chromium/Chrome.
Framework
Support libraries for integration with natural or programming language test frameworks, like Selenium with Cucumber or Selenium with TestNG.
Here could be a detailed tutorial on Selenium Webdriver.
How it Works: The WebDriver protocol contains a local end (‘client’) that sends the commands (test script) to a browser-specific driver. the motive force executes these commands on its browser-instance. So, if the test script implies execution on Chrome and Firefox, the ChromeDriver will execute the test on Chrome; the GeckoDriver will do the identical on Firefox.
Note: Test scripts execute only the WebDriver’s client and browser/driver are connected. They don’t need to air the identical device. To enable test execution on multiple remote drivers, you would like RemoteWebDriver and therefore the Grid.
Selenium Grid
The Grid can minimize test runtime—by executing multiple test scripts on any number of remote devices without delay. this is often called parallel testing.
Selenium Grid could be a smart server that routes test commands to browser instances on remote devices. the 2 main components needed for this (other than the test script from client-side/tester) are:
The ‘Hub’ (server):
Accepts access requests from WebDriver client. Routes JSON test commands to remote drivers on registered ‘nodes’.
‘Node’ (remote device):
Contains a native OS, browsers, and remote web driver.
How it works: WebDriver-client executes the test on a faraway device through a remote web driver. RemoteWebDriver is like your regular WebDriver, except its two components are the Client (your test script) and Server (a Java servlet that truly executes the test on the remote device).
In your test script, you define ‘desired capabilities’ (device, platform, browser, etc.) of the node where the test will execute. The Hub receives this script, runs through the registered nodes to seek out one that matches the specified capabilities, and assigns the test thereto for execution.
Note: putting in the Grid is pretty easy, but scaling, configuring, and maintaining its integrity can take up lots of resources. confirm to adopt it after careful consideration.
Selenium IDE
Selenium IDE could be a Chrome and Firefox plugin which will log ‘natural’ interactions within the browser and generate its code in programming languages like C#, Java, Python, and Ruby, further as Selenese (Selenium’s own scripting language).
Testers can enable ‘recording’ within the IDE and ‘play out’ the test scenario on the browser. The IDE can then replay those interactions and highlight any errors (during replay) in red.
Keep in mind that while the plugin is quick and helpful, the code generated is mostly too messy to be utilized in automation test scripts. So use it for rapid prototyping, except for more serious cross-browser testing, we recommend Selenium WebDriver.
Selenium: A History
A timeline of major events within the evolution of Selenium from an in-house side-project to an open-source industry-standard in browser automation:
2004: Making history in two parts (from Selenium A to B)
• Jason Huggins of ThoughtWorks must test his web app’s front-end behavior across different browsers.
• He develops a tool that works by injecting JavaScript underneath the webpage, allowing the tester to put in writing code that might ‘automate’ front-end user interactions. This became the JavaScript TestRunner.
• Although the JS-injection approach couldn’t naturally replicate user interactions (via keystrokes/mouse movements), it absolutely was a workaround for the ‘same-host origin policy’, which prohibits external JavaScript code from accessing elements from a website it didn’t originally reside in. Nonetheless, the tool is positively received by in-house developers and ThoughtWorks’ clients alike.
• The tool is open sourced thanks to popular demand.
• To eliminate the requirement for JS-injections, Huggins, together with colleague Paul Hammant, discuss the chance of a ‘server’ component. This server would act as an HTTP proxy and trick the browser-instance into believing that the test script and also the web app under test are from the identical source.
• They develop the server component in Java and also the original client-side driver (TestRunner) gets ported to Ruby.
• This is that the original Selenium. referred to as Driven Selenium or Selenium B within the evolution timeline.
2005: Selenium RC (Remote Control)
• Elsewhere (at Bea, specifically), Dan Fabulich and Nelson Sproul begin engaged on the motive force coder. They eventually mold it into a standalone server that bundled MortBay’s Jetty as an HTTP proxy.
• This becomes ‘Selenium RC (Remote Control)’ or Selenium 1.0. Before we move 2.0, there's another significant development within the form of…
2006: The Selenium IDE
• Shinya Kasatani wraps the Selenium driver code in an IDE module in the Firefox browser.
• When it works, he finds that he can run a functional ‘live test’ on a website—interacting with the browser (as a user would); recording/replaying the interactions, and debugging as required.
• Kasatani donates this tool to the Selenium project where it becomes called the Selenium IDE.
2007: The Selenium WebDriver (Selenium 2.0)
• Back at ThoughtWorks, Simon Stewart diligently codes up separate ‘driver’ clients for each popular browser, so they’d all support automation with native browser capabilities.
• It pays off. The project becomes famous because of the WebDriver.
2008: Multiply by ‘n’: The Selenium Grid
• At ThoughtWorks, Philippe Hanrigou creates a server that might allow testers to access and run tests on browser instances on any number of remote devices.
• This becomes called the Grid. Cut to…
2016: Selenium RC gets deprecated and WebDriver becomes standard implementation—aka Selenium 3.0.
2019: WebDriver becomes a W3C standard protocol
Who Uses Selenium?
Short answer: Everyone who cares about the state of their web app.
Part of the rationale of why Selenium is so popular is its flexibility. Anyone who codes for the online can use Selenium to check their code/app–from individual freelance developers running a fast series of tests for debugging to UI engineers doing visual regression tests after a brand new integration.
In an enterprise environment, testing with Selenium falls under the purview of QA engineers. they're tasked with writing focused, non-flaky (i.e., deterministic) scripts to maximize test coverage and accuracy, refactoring old test suites for newer versions of the project, and maintaining test infrastructure (from the Hub to the test-case library).
They would be those creating comprehensive test suites to pinpoint ‘show-stopper’ bugs and advising stakeholders about updating performance benchmarks for the project. Their end goal is to confirm maximum test coverage and efficacy, which successively boosts the productivity of the engineers at work
Comments
Post a Comment