Page Object Model in Test Automation

Writing initial automation scripts is an easy task. We need to just locate the element and perform necessary operations required in the test case. For a small script, maintenance is easy and small change in UI/UX would not create many problems. But with increasing test cases, the scripts will also grow. So with increasing lines of code, the maintenance starts becoming tough. For example, if you have ‘n’ different scripts written which consist of text box element and say in the future there is a change made to that element (Removed/Position Changed). In this scenario, you will need to make changes to ‘n’ number of lines. This ends up becoming time-consuming as you will need to go through that many lines of code and may also be error prone as you might miss out a couple of places.

Page Object Model (POM) approach for script maintenance is to create a separate file and place all the element locators of the common web page in that file. E.g. All the elements of the login page will be kept in one common file which is allocated for the login page only. This file is called the page object file of the login page. So whenever you want to use an element from the login page, you can directly use it from the Page object of the login page. So in future, if there is a change in that element, all you have to do is make the required changes in the page object file and the rest of the code will work as expected. This approach makes code maintenance much easier.

Page object will consist of all the elements of the corresponding and also the common actions performed on that page. These are called commands and they are written as functions. So when you want to use them, just make a function call. This is significantly helpful in reducing the code lines because very often, there are similar test cases where you perform similar actions but in different sequences. So instead of writing that action multiple times in different sequence, we can just make function calls in a different sequence.

Another advantage of POM approach is that the code becomes much cleaner and readable.

For example,

locator of Submit = #identifier

Case 1: Normal Approach

So when you want to click submit button, the syntax will be:

.click(‘#identifier‘)

Case 2: With Page object model

For this case, the locator of the Submit button will be already present in the corresponding Page object file. So the syntax for clicking the submit button in test file becomes:
.click(‘@submit‘)

In case 2 it is much easier to read the operation perform. So this becomes much easier to debug if the test code fails in future for some reason.

In Test automation, the Page object model can play an important role as it makes the code more readable, maintainable, reusable and helps avoid duplication.

Dattaraj Naik