Want to handle UI changes with ease, write more tests in less time, lower impact, reduce the lines of code, keep test logic isolated, & up your frameworks reusability?

If so, check out the page object pattern, AKA the Page Object Model.

This design pattern is used by most companies to build their test automation framework.

The page object pattern or page object model is one of the middle layers of your automation framework.

The Problem

The problem with most end-to-end / UI automation frameworks is they tend to be fragile.

Testing the top layer validates what’s below, but changes made in lower layers can take down your system.

This is a double-edged sword of front-end test automation.

Another common myth of automation is that UI test are hard to maintain.

The page object pattern helps solve both of these problems.

How Does The Page Object Pattern Work?

Each page of your application will have a related class. Inside of these containers is the logic to work with each UI element found on that page.

You’ll also want to add methods for common interactions on that page.

So let’s say we’re creating a page object for a login page. We’ll add ways to enter in the login credentials, and click the login button.

Creating a method that can handle logins in one call is also helpful.

Page objects shouldn’t make assertions. Objects just provide access to the page. Leave it to the test clients to carry out the assertions.

The Main Advantages Of Page Object Pattern

What’s nice about this is the test code is much cleaner, because the framework becomes independent. The amount of code you have to maintain is reduced, and each page object is reusable.

This type of pattern allows navigation chaining. Methods in Page Objects can trigger events that then return the next Page Object.

Key Point

The goal of the page object pattern is to avoid scattering UI interaction code in your test and maintain it in one area.