With web applications becoming the defacto approach to developing end user applications,a solution for testing is needed.This has meant more and more emphasis is needed on a browser automation framework to help with checking the site.
For years people have been using Selenium IDE and Selenium RC to drive a number of different types of browsers. Selenium, when originally created by Jason Huggins, solved the issue of getting the browser to do user interactions.
The Selenium API was originally designed to work from within the server. The developer or tester writing the tests had to do so in HTML using a three column design based on the FIT. You can see how this looks if you open up Selenium IDE: the three input boxes that need to be completed for each line that will be executed. It has a number of issues in that you cannot do anything that you may do with a Turing complete language.
Patrick Lightbody and Paul Hammant thought that there must be a better way to drive their tests and in a way that they could use their favorite development language. They created Selenium Remote Control using Java as a web server that would proxy traffic. It would inject Selenium onto the page and then it would be used in a similar manner as to what it was in the three column manner. This also creates more of a procedural style of development.
The Selenium RC API for the programming languages that are supported have been designed to fit the original three column syntax. Commonly known as Selenese, it has grown over the life of the project to support the changes that have been happening to web applications.This has had the unfortunate consequence that the API has grown organically so that users can manipulate the browser the way they intend but still keep to the original three column syntax. There is somewhere in the region of 140 methods available which makes picking the right method for the job rather difficult.
With the move to mobile devices and HTML5, Selenium RC was starting to show that it wasn't able to fulfill its original requirement: browser automation to mimic what the user is doing.
Simon Stewart, having hit a number of these issues, wanted to try a different approach to driving the browser. While working for Thought Works, he started working on the WebDriver project. It started originally as a way to drive HTML Unit and Internet Explorer but having learnt lessons from Selenium RC, Simon was able to design the API to fit in with the way most developers think. Developers have been doing Object Orientated development for a while, so moving away from the procedural style of Selenium RC was a welcome change to developers. For those interested I suggest reading Simon Stewart's article on Selenium design at http ://www.aosabook. org/en/ selenium.html.
The next section will go through the basic architecture of WebDriver./p>
Selenium Related Interview Questions
|SILK TEST Interview Questions||QTP Interview Questions|
|JMeter Interview Questions||Automation Testing Interview Questions|
|Software testing Interview Questions||JUnit Interview Questions|
|TestNG Interview Questions||SAP Testing Interview Questions|
|Selenium WebDriver Interview Questions||Selenium IDE Interview Questions|
|QUnit Testing Interview Questions||Performance Testing Interview Questions|
|Hadoop Testing Interview Questions|
Getting Started With Selenium Ide
Overview Of Selenium Webdriver
Working With Webdriver
Getting Started With Selenium Grid
Advanced User Interactions
Working With Html5
Migrating From Remote Control To Webdriver
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.