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

Consultant
Leave a Reply

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

Related Blog Posts
Rockstar Development
This originally appeared on Marty Henderson’s personal blog Or, how to use Gitpod and GitLab so that no one else has to care about your questionable coding language choices. A true rockstar has a good […]
Testing a Quarkus Kafka Application
Quarkus, a “Kubernetes Native Java stack,” enables lighter Java applications with faster startup times. In a recent post, I talked about scaling Kafka consumers in Kubernetes. Quarkus applications fit right into this picture because they […]
Gitpod and Hringvegurinn
Iceland Ever seen an advertisement for visiting Iceland? Have you noticed that they all mention Hringvegurinn or the Ring Road, as a good tour? (If you haven’t seen a tour ad for Iceland, Steindi Jr […]
Tacos and Steak, an Istio story
This post originally appear on Marty Henderson’s personal blog A brief history In the before times of 2017, Varun Talwar and Louis Ryan sat under a forgotten waterfall at the edge of the world and […]