Since the days Automation became popular, there are multiple ways in which automation can be done. One effective way is the usage of Automation Frameworks. So that brings us to the question of what exactly is an Automation Framework.

Automation Framework

There may be varied responses to this question. Some would say the framework is a set of functions and routines that facilitates automation script development and execution. I have heard that frameworks are an abstraction layer that structures automation design and implementation. For me, to put it in simpler words, a framework might be a combination of above or more which solves the typical problems that an Automation engineer faces namely

  1. Maintainability
  2. Managing Code Redundancy
  3. Scalability
  4. Re usability
  5. Robustness

There are lot of frameworks in the market which would solve few or most of the above problems. But one of the most effective framework that I have used is the Page-wise Framework (If I could term it so).

In addition to the above problems which the page-wise framework effectively solves, there are a few other factors that should be considered while choosing the page-wise framework to make it more effective.

  1. UI based Application(Application under Test)
  2. Application with constant addition/modification of features
  3. Application with Multiple Pages
  4. Object Oriented Programing Language to write the Automation Code.

Even though the above mentioned factors are not mandatory to look into, it’s always good to keep these factors in mind while going ahead with the page-wise framework.

So let’s go over the Page-wise framework.

Page-wise Framework

features_new

Page-wise Automation framework uses the Object Oriented approach. Let’s look at how it solves the typical problems that I mentioned earlier.

  • Easy to Use– Each Page in UI has a corresponding Class in Automation making a 1:1 mapping between the UI and automation. So it’s much easier for a novice to start working on it as compared to any other frameworks as the code is intuitive.
  • Reduces Redundant Code – since the UI elements of a page resides in a corresponding class file in automation, declaring components at multiple places is avoided thereby reducing redundant code.
  • Robustness– Since the structure is similar to the UI, It is much easier to handle any UI changes or any changes to an existing component.
  • Scalability– Automating new features is much simpler as the framework is well structured and is similar to the UI on which the automation is done.
  • Re usability– Since all the UI components and its instances resides on pages, it can be called from different tests without initializing them every time.

Let’s look at the architecture. I have taken Selenium API as the base, however it should work with any other tool.

architecture

So let’s go over the architecture.

The Pages and Dialogs have the UI component declaration with a getter and setter method for each individual UI component. The getter methods typically gets the UI component (to be interacted on) and the setter method performs the action on that component using the Selenium API (in this case).

Then you create the common methods out of the getter and setter methods of each page depending on the functionality that has to be replicated.

So once you have your common methods ready, you create your testcases depending on the requirements/functionality.

Let’s implement the page framework for a simple mail application. I have used Selenium web driver API with Java as the background language.

Here’s how the project structure would look like. All the pages in the application has a corresponding java page and all the pages are segregated into a package.

Project_Structure

Let’s take a look at the login page. If you look at the code, each UI component in the page has a declaration and its corresponding getter and setter methods. There by u get a 1:1 mapping with the application.

Page_Code

The helper methods are created using the components and its methods in the pages.

The actual tests are written as part of the test package using the helper methods created.

Let’s look at some practical problems and how the Page framework solves it.

  1. Code Redundancy– Let’s take a use case where in you have to click the same button as part of 10 different testcases. In the case of page framework, you create the instance of the component only in your page class and just call that in all of your testcases. So that saves us “n” number of lines (Where n will be the number of times the same component is created across the project) compared to any other automation framework.
  2. Re usability and Robustness– Let’s take a use case where in components related to a page change. There might be 2 kinds of changes
  • ID change of an existing component– In the page framework, since all the components of the page in UI resides in a single class file, there would be “only one” place to modify as compared to multiple places in other frameworks.
  • Addition of a new component– Again as it’s a 1:1 mapping between the UI and the class file, you just need to find out the page where the component is added and add it to the corresponding class file. If you consider the same scenario for any other automation frameworks, the changes would be at multiple places (places where all the ID’s are declared).

Though the above mentioned problems might be reduced by declaring all the components in a single file, maintainability will be a huge challenge as the file keeps growing. Also there is always a possibility of duplication.

In my next blog, I will talk about how the page framework can be implemented for a complex application (maybe an application with multiple pages and dialogs).