Contract POM

In current times, Test automation is an essential subset of software testing. Automated testing,
helps us by expediting the process of software validation and increase testing coverage. To
develop a good automation framework, the key is to choose an appropriate tool, architecture and
design pattern that will help you achieve the maximum ROI. Page Object Model is the most used
design pattern suitable for medium to large scale application under test.

What is Page Object Model in Selenium?

Page Object Model, also known as POM, is a design pattern used to create an object repository
for storing all UI web elements. It is useful in reducing code duplication and improves test case
maintenance.
In Page Object Model, consider each web page of an application as a Page class file. Each class
file will contain corresponding web page elements and methods that perform operations that a
user can do on those webElements. This methods should be named as per the action they are
performing I.e., If it perform input of username in username field of a form, setUsername or
inputUsername should be the name of the method.

What are the advantages?

• Code Re-usability
• Easy maintenance
• Readability and reliability of Code

As we start building with POM we have very high expectation from the design pattern and we
should have as it has promising advantages but when automating a large scale application the
number of pages and scripts goes up in no time and number of people need to be involved to
speed up the process of automation that introduce further challenges in framework maintenance.

Let’s understand with an example, if we have a login page, there are numerous way of writing an
action method in page class.
• Writing a single method that will log you in,
public boolean login(String username, String password)
• Writing a single method for each action
setUsername(String Username)
setPassword(String Password)
clickLoginButton()

Even for the second option a QA can use different strategy
• public void setUsername(String username)
• public boolean setUsername(String username)
• public LoginClass setUsername(String username)
• public void clickLoginButton()
• public NextPageClass clickLoginButton()

Some QA even go further and add methods that should not be part of POM, for example a
requirement came into picture to store password as encrypted in your data sheet and one might
go and add a method in your LoginPage class.
public String decryptPassword(String encryptedPassword)

Functionality wise they all will work fine and your test scrips might will execute smoothly but it will
introduce major challenges in code maintenance and reduce code re-usability.

Lets have a look at the strategies to improve overall re-usability and maintenance.
We can follow below principal/rules, when we are writing an action method in POM

A - Action method return page instance

Each action method in POM should return an instance of the page class where user will
be, after the action is performed. Again take a look for LoginPage:

R - Relevant data structures

There might be scenario where we are getting data from the application pages, in that
case POM method should store the data in appropriate Data types or collections and return it.
Let’s take an example of table on a page of application from which we need to extract the data.

We need to store this data in a collection that easily represent the table and can be iterate I.e.,
List<List<String>>, List<String[]>, List<HashMap< String, String>> etc

Follow the SOLID principal of OOP

S - Single Responsibility

O - Open/Closed

L - Liskov Substitution

I - Interface Segregation

D - Dependency Inversion

To follow these principal in your framework when there is a large team involved can be very
stressful. You need to prepare detailed documentation and provide training to the team on how
to use the framework and what compliance need to be followed while writing the POM. In
addition to that a lot of time will be getting consumed in review process of the code

What is the solution?

Lets Introduce Contract (Interface) POM in our framework
What is a contract? A contract is a document between at least two parties that defines and
governs the rights and duties of the parties to an agreement.
Let’s Understand it with business value of application under test.
Each page in application has a set of element and user are bound to perform only a set of action.
This can be formulate as a contract for test implementation of that specific page, that will provide
QA a clear scope what need to be implemented.
Lets see a simple pattern/Structure we follow in Page Object Model

In above Structure we are keeping UI WebElement and Action methods in separate classes for
better maintainability and we even have BasePage class that contains Elements and Methods for
common modules like header, footer, loader etc.

Now the Contract POM comes in picture as interface

Lets add an interface for our LoginPage and apply S- single responsibility principal

As you can see ILogin Interface is comprise of all the business value action that can be performed on
Login Page of application and each action method have a single task that it will be performing. Here we
have created structure that follow up the Principal that we earlier talked about without worrying about the
implementation.

Now when a QA pick up a task of implementing Login functionality he just need to implement Login
interface in his POM and he will have all the action method that need to be implemented.

Now out Login page class will look like this:

.

Now lets go one more step further and apply I – Interface segregation principle

We are already using a BasePage class that all the common modules like header and footer, but
sometimes that will lead to a very large BasePage class. Many developers find it easier to insert a new
feature into an existing class than to create a new class for it. Over time, this can lead to what some call
“Large Class” syndrome, in which classes become large, inefficient and very hard to maintain.

Consider each PageObject not as an object representing a single page, but as objects within a
page. Think of each object as a widget or page component. Now let’s take look at our login page.

As we can see header and footer are two different module which have completely independent
functionality and business logic, keeping them in a same class will just bulk up our BasePage.
Even for header search and navigation menu has no dependancy so let’s separate them too.

Then your BasePage should go like this

What are the advantages of this contract based POM design?

For QA Developers:-
• Provide a clear scope of what need to be implemented and business logic,
• Give exact method signature,
• Make code loosely coupled,
• Make your code easy to enhance, debug and fix.

For Leads:-
• Reduced review time whenever a QA commit some code,
• Makes it easier to estimate changes,
• Code is well structured and easy to maintain.