How Does WebDriver ‘Drive’ the Browser Compared to Selenium-RC?

Selenium-WebDriver makes direct calls to the browser using each browser’s native support for automation. How these direct calls are made, and the features they support depends on the browser you are using. Information on each ‘browser driver’ is provided later in this chapter.

For those familiar with Selenium-RC, this is quite different from what you are used to. Selenium-RC worked the same way for each supported browser. It ‘injected’ JavaScript functions into the browser when the browser was loaded and then used its JavaScript to drive the AUT within the browser. WebDriver does not use this technique. Again, it drives the browser directly using the browser’s built in support for automation.

Flavors of selenium

Selenium comes in 4 flavors.

1)      Selenium IDE – record and play back tool for beginners. Comes as a plugin for Firefox browser.

2)      Selenium RC (Remote Control). Works as remote server. Its available in selenium 1.x

3)      Selenium Webdriver which supports almost all browsers and operating systems.

4)      Selnium Grid. It is useful when we have run tests on different browsers and operating systems simultaneously.

Selenium - a brief Introduction

Selenium is mainly developed for automating web applications. It supports only web applications.

It doesn’t support desktop applications.  Selenium is used for regression testing, performance and load testing.

Types of Automation Framework

These are very popular definition of different types of frameworks available in the market 

Script Modularity Framework
The test script modularity framework requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case.

Library Architecture Framework
The test library architecture framework is very similar to the test script modularity framework and offers the same advantages, but it divides the application-under-test into procedures and functions instead of scripts. This framework requires the creation of library files that represent modules, sections, and functions of the application-under-test. These library files are then called directly from the test case script.
Keyword-Driven or Table-Driven Testing Framework

Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.

Data-Driven Testing Framework
Data-driven testing is a framework where test input and output values are read from data files (datapools, ODBC sources, cvs files, Excel files, DAO objects, ADO objects, and such) and are loaded into variables in captured or manually coded scripts. In this framework, variables are used for both input values and output verification values. Navigation through the program, reading of the data files, and logging of test status and information are all coded in the test script.

Hybrid Test Automation Framework
The most commonly implemented framework is a combination of all of the above techniques, pulling from their strengths and trying to mitigate their weaknesses. This hybrid test automation framework is what most frameworks evolve into over time and multiple projects.