Page Object Model for UI Testing

Software companies are taking more strides to produce quality code. In order to do that they increase the testing for their applications. One of the testing methods used is UI testing, validating the client facing application is behaving as expected. Within the UI testing space there is one method of writing tests that has been at the front of UI testing for many years, Page Object Model or POM. POM treats each “page” in an application as an object in code for example in C# a page might look like:

Public class HomePage(){

Public By SearchButton ( get; set; )


Obviously, an actual page would have many more properties but that is the general idea. Once a “page” is defined you perform an action on the property (element on the page). So, on the search button you would probably perform a click action. The actions are typically in a separate class which is then pulled into the test.

Though the POM method is very common it has some very distinct advantages and disadvantages.

First some of disadvantages:

1. It is very easy to write unmaintainable code

a. As you can see from the above example, as the complexity of an application grows so must the pages and actions in your test grow. Navigating and debugging through the code becomes more difficult.

2. Code can be very fragile

a. With UI testing there are many challenges to overcome such as changing element IDs, servers being down, etc. Knowing there are challenges, steps can be taken to ensure resiliency when tests encounter these issues but if it is not designed to do that from the beginning then going back and adding it afterwards will be a nightmare.

3. Debugging can be a nightmare

a.  Testing becomes increasingly more complex as the test is trying to perform actions that utilize more elements and the challenge of debugging increases at the same rate.

In order to alleviate some of the disadvantages there are hybrid patterns that utilize development best practices such as the screenplay pattern that may be the right pattern for you to utilize. Screenplay pattern steers engineers towards an effective use of layers of abstraction and encourages good testing and software engineering habits. As with anything there are disadvantages that may steer people away from implementing a POM testing framework or some variant thereof but there are some advantages that go with it as well. 

1. Easy to track what pages have classes

a. If POM is being used “correctly” it can be very simple to see what is being tested and what isn’t. Find the class that corresponds to the page and verify the elements are there and then if you want to take it further you can check that each of those elements are being pulled into an action and then a test.

2. Only one place to check for correct element locator

a. One of the most common failures in UI testing is a change in the page itself. Often a person writing a front end may make a change to an element without realizing the repercussions and break the test. If that happens there should only be one place to check that the correct locator is being used.

3. Can be very easy to debug

a. If a POM framework is built “correctly” it can be very easy to debug and find where failures are happening. With the ease of being able to find where failures are happening it cuts down the time it takes to find and fix increasing time that can be used adding tests elsewhere.

I have seen many people’s spin on what POM can look like and do, some are better than others. Whether you choose to use POM or not it can be an effective method for UI testing, but there is one major step that can be taken to ensure your page object framework isn’t becoming unwieldy and hard to maintain.

  1.  Think about page components more than pages
    1. Having pages that get complex and big can be hard to maintain but splitting up the page into smaller classes by component can help with code management.

If you are able to split into components instead of pages it can make the huge page classes much more manageable.

About the Author

David Larsen profile.

David Larsen

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
An Exploration in Rust: Musings From a Java/C++ Developer
Why Rust? It’s fast (runtime performance) It’s small (binary size) It’s safe (no memory leaks) It’s modern (build system, language features, etc) When Is It Worth It? Embedded systems (where it is implied that interpreted […]
Getting Started with CSS Container Queries
For as long as I’ve been working full-time on the front-end, I’ve heard about the promise of container queries and their potential to solve the majority of our responsive web design needs. And, for as […]
Simple improvements to making decisions in teams
Software development teams need to make a lot of decisions. Functional requirements, non-functional requirements, user experience, API contracts, tech stack, architecture, database schemas, cloud providers, deployment strategy, test strategy, security, and the list goes on. […]
JavaScript Bundle Optimization – Polyfills
If you are lucky enough to only support a small subset of browsers (for example, you are targeting a controlled set of users), feel free to move along. However, if your website is open to […]