Swarm of XeBees

• Tweet
• Sharebar

• Tweet

I have dealt with automation of multiple types of applications at its core level whether its desktop app, Silverlight app,or windows application.

When we talk about web application automation, the most widely used automation tool is Selenium. Selenium is open-source tool and this makes selenium more powerful than any other tool.

Now as Selenium-Webdriver (Selenium 2) has been released, everybody ask one question whether to switch to Webdriver from Selenium-Remote Control. So I would be discussing here the core technical differences between the two, as basic differences are already available at various places.

Following are some technical differences between Selenium's two flavor ie.WebDriver and RC.

• Web Driver is designed to accurately simulate the way that a user will interact with a web application.A common approach for simulating user input is to make use of JavaScript to synthesize and fire the series of events that an app would see if a real user were to perform the same interaction.This "synthesized events" approach is fraught with difficulties as each browser, and sometimes different versions of the same browser, fire slightly different events with slightly different values.To complicate matters, most browsers won't allow a user to interact in this way with form elements such as file input elements for security reasons.Where possible Web Driver uses the alternative approach of firing events at the OS level. As these "native events" aren't generated by the browser this approach circumvents the security restrictions placed on synthesized events and, because they are OS specific, once they are working for one browser on a particular platform reusing the code in another browser is relatively easy.

• The WebDriver developers lean more towards finding and isolating the complexity in a few places rather than spreading it out. One reason for this is users. As an example, consider the following methods from the original Selenium API, each of which can be used to set the value of an input element : type, typeKeys, typeKeysNative, keydown,keypress,keyup,keydownNative,keypressNative,keyupNative,attachFile. Here's the equivalent in the WebDriver API: sendKeys

• WebDriver Design : The Webdriver team refers to WebDriver's API as being "object-based". The interfaces are clearly defined and try to adhere to having only a single role or responsibility,but rather than modeling every single possible HTML tag as its own class webdriver developer only have a single WebElement interface. The result is that coding sessions may look like this (in Java):

WebDriver driver = new FirefoxDriver();

driver.<user hits space>

At this point, a relatively short list of 13 methods to pick from appears. The user selects one:

driver.findElement(<user hits space>)

While RC doesn't define a webelement rather it get the object at run time based on the locator given by user. This result in coding session like this

Selenium selenium = new defaultSelenium(<host>,<port>,<browser>,<url>);

selenium.click(<locator>);

Apart from cleaner Api,this webdriver approach allow user to do lot of manipulations based on requirements with Object before performing actual operation on test  object.

• Selenium makes use of a layered set of libraries as a mechanism to interrogate the DOM. The bottom layer is Google's Closure Library, which supplies primitives and a modularization mechanism allowing source files to be kept focused and as small as possible.. Within the project, these are viewed as offering the smallest units of browser automation, and so are called Browser Automation Atoms or atoms. Finally, there are adapter layers that compose atoms in order to meet the API contracts of both WebDriver and Core.



Looking future of Webdriver:

There will always be browsers that WebDriver can't integrate tightly to, so there will always be a need for Selenium Core. Migrating this from its current traditional design to a more modular design based on the same Closure Library that the atoms are using is underway. Webdriver developer also expect to embed the atoms more deeply within the existing WebDriver implementations .

More details can be accessed from "http://www.aosabook.org/en/selenium.html".

In  next blog post, most probably I would be discussing on Webdriver's best usage to make automation reliable.

Thanks

Filed under: Uncategorized