Page Object Model

Writing test automation can only be guileless if developers agree they don’t touch the features that are automated. Though this can be dream come true for any test automation engineer, it contradicts objective behind automation, automation is written to catch early bugs in development and to avoid manual testing to some extent.

Automation that began with ease and confidence can end up with high maintenance increasing cost and become a de-motivating factor for the team. A single change in identifying one element can end up updating all automation tests. So no doubt its better to plan and analyze needs for automation and choose an easy to build and maintain the approach that suits best your team. You can go to our blog on designing test automation framework, which can help you in deciding your requirements. In this article, we are going to look in Page Object Model to write maintainable and reusable tests in automation.
Page Object Model
As name highlights, the approach is based on page object repositories. In simple words, we need to create page objects for every page or screen in our application. The object should contain, all the elements on that page and any actions specific to that page. If app contains very huge pages, we can split the actual page into different panels in the page and have classes for panels instead of pages.

For example, with Login page in the app, we can have login page object containing, username input, password input and submit button as elements and login into the app as an action method.

Login page object:

From implementation point, here object is the class instance, so we need to write page class including its elements and actions. Writing this is different syntactically in various languages.

Here’s an example from Java:

public class LoginPage {
private static final By usernameInput = By.id("username");
private static final By passwordInput = By.id("password");
private static final By loginButton = By.id("login");

private WebDriver driver;

public LoginPage(WebDriver driver) {
this.driver = driver;
}

public void loginIntoApp(String username, String password) {
driver.findElement(usernameInput).sendKeys(username);
driver.findElement(passwordInput).sendKeys(password);
driver.findElement(loginButton).click();
}
}

Why?

• With page object model, we can have all element locators for the page in single class.
• It gives us modular approach, which avoids duplication and also makes it easy to maintain.
• Having page action in page class creates wrapper layer above automation library like web driver, which makes adding new tests easy and quick.
• It keeps tests and page specific code different.
• Actual tests look clean and small, as we don’t have to write actual actions in a test. They are written in page class.

When?

• This is one of the popular approaches choose many teams but that should not be criteria for choosing it for automation.
• If your application consists of different pages and if you have modularised your tests page-wise, then this approach should suit you best.

Not For?

• In our opinion, this approach does not suite for more dynamic pages in an application or for an application which is feature based more than UI based, which means their UI for pages is dynamic but the application has consistent features. There are some other approaches to look at this cases. You can get more details more these on our other blogs.

If you are already using page object model or tried using it, share your experiences with us in below comments