Page Object Model (POM) is used as a design pattern in test automation for websites and applications. POM is to create an object repository for the pages in the application/website, which can be used in the tests. In other words, instead of including the page elements and the test code together within the test, separate them into 2 different entities as the pages and the test flows. Using this concept, each page in the application will have a corresponding page class. The page classes will identify
the elements in the page and contain methods that perform operations on these page elements.

Initially, we had Legacy Applications which had one page and when the user clicked on a button then refreshed the browser and loaded a new page.

If we define a page object model for the above, we are declaring each page.

Class DownloadProjectPage
{
Webelement FullName;
Webelemet EmailID;
Webelement
PhoneNumber;
}

After the above model, we got Single-page Applications (SPA). It has mainly one page and loads the components. It is only loading some sections for a particular action and other sections are static. Some examples of Single Page Applications are
Gmail, Google Maps, Airbnb, Netflix, Pinterest, Paypal, and many more.

For this type of application, we need to structure the loading components first.

As per the above example page, we can define three page-objects. The third section can have another page object based on user selection. E.g., Primary, Social.

class LeftMenuBar
{
< >
}
class TopMenuBar
{
< >
}
Class Promotions
{
< >
}
class Primary
{
< >
}

These Page Object classes can be reused across your entire test suite and give you the opportunity to implement automated tests for your projects early on. By abstracting away user interactions in your page object models and keeping your test routines light and simple, you can adapt your test suite to changing requirements with little effort.

These are some of the benefits of using a page object model for a test automation framework.

• Uses a class hierarchy for common components.
• Each element in the entire application/website is mapped exactly once.
• Reduces code and code duplication.
• UI change fixes are done in one place.
• Independent of test cases, can use the same object repository for a different purpose with different tools. (e.g., Integrate Page Object Model in Selenium with TestNG/JUnit for functional Testing and at the same time with JBehave/Cucumber for acceptance testing.)
• The amount of code becomes less and optimized because of the reusable page methods in the POM classes.
• Methods get more realistic names that can be easily mapped with the operation happening in UI. (i.e. if after clicking on the button we land on the home page, the method name will be like ‘gotoHomePage()’.)

POM makes Test script code more maintainable for future changes as well as reduces the duplication of code. All these benefits become useful when testing complex large-scale applications. And we all know that large and complex applications only tend to grow larger and become more complex.

Author: Kanishka Gamage is an ISTQB-certified Quality Assurance Test Lead at CMS with 12 + years of experience.