Introduction to the integral Framework

INTRODUCTIONTO THE

INTEGRAL FRAMEWORKBY

KARTHIK SUBRAMANIANhttps://www.linkedin.com/in/karsub1

karsubp@gmail.com

Introduction to the Integral Framework

One definition of the word Integral is: consisting or composed of parts that together constitute a whole.

The focus of this framework is Simplicity. By creating and maintaining easy-to-understanding parts, it is possible to create and maintain an easy-to-understand whole. Simplicity here means minimizing the key resources involved in the framework and making sure those resources follow clear lines of communication with each other.

The Integral framework places a majority of its emphasis on Description Objects, Component Scripts and Actions, Function Libraries (VBS files), Driver Scripts and Actions and Master Scripts and Actions. The Following Diagram shows a simplified hierarchy of these resources.

VBS

Components

Master

Driver Driver Driver

VBS

Description ObjectsInstead of using the Object Repository feature in Quick Test Pro (QTP), each component action will use explicitly defined Description Objects which are property name/value collections used to identify an object within the Application Under Test (AUT)

Component ScriptsComponent Scripts are composed of very small, reusable, automated pieces of functionality within the AUT. Examples of component actions include entering text in a field or clicking on a Button

Function LibrariesExternal functions and subroutines written as VBS files can be an extremely valuable way to reuse code in an automation framework

Driver ScriptsDriver Scripts are composed of reusable actions that dictate the order in which component actions are executed so that a user experience in simulated. The focus of a driver script is on page-specific activity.

Master ScriptsMaster Scripts decide the order in which driver scripts are executed so that a full, end-–to-end test scenario can be simulated. The focus of a master script is on system-wide activity

Component ScriptsEach component script contains a collection of reusable actions that can be used to manipulate or validate objects on a particular screen in the AUT. Separate component scripts should be created to handle areas of the screen that appear on more than one screen (e.g. a navigation banner at the top of the left of the screen that appears on most of the screens). Popup windows and dialogs should be considered different screens within the AUT and should have corresponding component scripts as well. The following illustration shows how each object on the AUT screen has a corresponding reusable action in the component script

Component script Application Under Test

= Reusable Action

Login

Username

Password

Login

Enter Username

Enter Password

Click Login

Component script Application Under Test

= Reusable Action

Component Action TypesThere are two main types of component actions within the Integral Framework: manipulation actions and validation actions. Manipulation actions are those actions that do something to an object on the application’s user interface. Validation actions are those actions that check something in the system, comparing an expected value against an actual value or application state. The following illustration shows how component actions can be used to validate or manipulate specific objects in the AUT.

Component script Application Under Test

ValUsername

ValTodaysDate

ClickStart

Welcome

Welcome SunRaise!

Today’s Date: January 1, 10

Start

Component script Application Under Test

= Reusable Action

Creating Component Scripts/Actions

Input ParametersInput parameters are used to pass information to reusable component actions. An action that handles entering text into a text field will have an input parameter that specifies what text should be entered into the field. Input parameters, depending on the parameter type (i.e. String, Number, Boolean, etc.), might utilize a default value when a similar value will often be passed into the action. Output ParametersOutput parameters can be used to return information back to the calling driver action. Output parameters are typically used to retrieve information that is generated by the AUT and that is needed later during the automated script’s execution 

Referencing External FilesWhen multiple components actions use very similar code to perform their object manipulations, the code is a good candidate for reuse by moving it to an external file. The following illustration shows how two component actions that contain similar code can reuse code by moving the logic to an external file and simply calling the external file.

WebEdit_EnterText.vbs

Moving code to an external file not only allows the code to be referenced more easily by component actions but it also allows for simpler maintenance of the code since it’s only in one place. Imagine if the logic of enter text was in 500 components actions and then had to be updated. One would have to make the logic update in 500 places instead of just one.

Use the ExecuteFile command in QTP to retrieve the external file and put the file’s code into memory for execution. In the previous example, Both EnterUsername and EnterPassword actions would need to perform the following command before the calling the subroutine in the external file.ExecuteFile “WebEdit_EnterText.vbs”

Description ObjectsThe Integral Framework uses description objects instead of object repositories to identify objects in the AUT. Using description objects allows the engineer to be very specific when defining the property names and values to use when identifying the object being manipulated or validated. Storing property names and values in object repositories requires additional space and processing during script execution since it forces QTP to create and reference an XML file where all the property names and values are stored and then create description objects based on those properties. It also avoids identifying similar fields on different pages. By manually creating description objects, engineers can save space and skip extra processing required by QTP.

The following example code shows how to create a description object and assign a property or properties name/value pair to it.‘Set aside memory for the description object variableDim descrWebEdit

‘Create the description object and assign it to the variableSet descrWebEdit=Description.Create()

‘Add the Property to our object, supplying as the property valuedescrWebEdit(“name”).value=”MyfeildName”

Note: Use the Object Spy tool in QTP to discover the properties that uniquely identify the object being manipulated or validated.

Piecing It all Together: Using Component ActionsThe following diagram shows an example of everything discussed thus far.

“SunRaise” is passed into the component action EnterUsername as an input parameter. Because EnterUsername handles only entering text into the Username fields, the action only needs to: (1) identify the field being manipulated, and (2) enter text into the field. Step (1) is handled by creating a description object that uniquely identifies the field on the screen. Step (2) is handled by the external file WebEdit_EnterText.vbs which contains a subroutine of the same name.

To enter text into the password field, the engineer would create a component action called EnterPassword where a description object is created to uniquely identify the Password field, and then make a call to the same WebEdit_EnterText.vbs.

Driver ScriptsEach driver script contains reusable actions that call component actions in a particular order to simulate a user experience on a particular screen in the AUT. While component actions focus on a particular field or object on a screen, driver actions focus on manipulating more than one object on the screenA user experience on a particular screen may involve manipulating one or more pop-up windows or may require navigating to and from another screen in the application in order to complete the activity. Manipulating pop-up windows and /or navigating to another screen should take place within the same driver action if, and only if, those extra steps are necessary to the activity.Driver scripts control which specific data is passed to the component actions it calls i.e. the username “SunRaise” should be passed from the driver action as an input parameter to the component action EnterUsername

Driver Action TypesThere are two main types of driver actions within the Integral framework: Independent actions and dependent actions. Independent actions are those actions that can be executed regardless of the application state. Dependent actions are those actions that can execute successfully only if the application is in a particular state (i.e., on a particular screen).

An example of an independent action might be creating a new user account in the system. An action such as creating a new record that does not rely on any other record being created previously can usually take place at any time while in the application. As long as the automated test can perform the necessary actions to return the application to a ‘start’ state (e.g. returning to a home page or login screen), the independent action can execute successfully.

An example of dependent action might be performing a task on the fourth screen in a wizard-like sequence of screens. Without first executing the actions that correspond to the previous screens in the wizard, the dependent action cannot execute successfully.

Creating a Driver scriptThe reusable actions that make up a driver script should be named in a way that clearly and concisely describes what the action is doing on the particular screen. An example might be AddUserAccount for a driver action that simulates entering in information for a new user account, submitting that information to the system and performing validation to ensure that the activity was successful.

Piecing It All Together: Using Driver Actions

The following illustration shows a driver action that enters a username and password and then clicks the Login button – in that order - to simulate a user logging into the system.Note that “…”denotes QTP Syntax that has been removed in this document

Driver Action: Login

Component Action

Component Action

Component Action

Application Under Test

WebEdit_EnterText.vbs

WebButton_Click.vbs

RunAction “EnterUsername”, …. ,”SunRaise”

RunAction “EnterPassword”, …. ,”Password”

RunAction “ClickLogin”, …

EnterPassword

Click Login

EnterUsername

Code to Enter text

Code to Enter text

Login

Username

Password

Login

SunRaise

**********

Driver Action: Login

WebButton_Click.vbs

Data ScenariosA data scenario is a collection of specific data that are used to populate fields, act as expected values for validations and otherwise drive an action to simulate the information a user might input into the system and expect to receive from the system as output. As an example, imagine that there are two user accounts in the system. Each user account has an associated username and password that must be used together in order to gain access into the system. The following table represents two possible data scenarios that could be used for the driver action Login shown above

Username Password1 SunRaise SunPassword12 Moonlight CoolWinter

By referencing the first data scenario in the Login driver action, the automation would simulate logging into the system as SunRaise. By referencing the second data scenario, the automation would simulate logging into the system as Moonlight. Note that the driver action would not have to be changed at all in order to perform either simulation. It would only be necessary to manage what input data was supplied to the component actions called in the driver action. This is where driver action input parameters are introduced.

Input ParametersInput parameters are used to tell the driver action which data scenario to use. Like component actions, a default value can be assigned to be input parameter for the driver action.

Piecing it All Together: Using Data Scenarios

The following illustration shows how a call from master action can dictate which data scenario is referenced by a driver action, thereby determining how the driver action will simulate a user experience.

Referencing External Files

There are two types of external files within the Integral Framework: AUT-focused libraries and framework – focused libraries. AUT-focused libraries are the functions and subroutines that are used by component actions to manipulate or validate the AUT. Framework-focused libraries are the functions and subroutines that are used within the framework itself to control execution flow and data.

Most AUT-focused libraries can be thought of as replacing the code that QTP automatically generates during a recording of an action. QTP might generate the following line after clicking a web button.Browser(…).Page(…).WebButton(…).Click

The Integral Framework uses a description object to uniquely identify the WebButton, and then passes that description object to the WebButton_Click subroutine managed in the external file WebButton_Click.vbs

Framework – focused libraries are designed to make the framework more easily maintained and flexible by implementing code reuse. Framework-focused libraries can contain functions that handle commonly used tasks (e.g. formatting data in a particular way) or dictate how the automation test should be executed (e.g. how many times an action should be executed and which data scenario to use)

.

Master Scripts

Each master action will contain only calls to driver actions in a particular order that simulates a user experience across more than one screen in the system. Each call to a driver action also contains the row number of the data scenario to use while executing. If more than one row number is supplied, the driver action will be executed once for each row number supplied and in the order that the numbers are supplied. This functionality should be implemented in the driver actions using a separate VBS file.

KARTHIK SUBRAMANIANhttps://www.linkedin.com/in/karsub1

karsubp@gmail.comMeet The Expert

Selenium – Page Object Framework Overview