Let’s talk about the Page Object Model, the pattern we adore in web automation.
We all love patterns. Take for example, the Singleton, which I wrote about in the past, and its inherent evily-ness. While we can argue if Singletons are evil or not, I just need to say the name “Singleton”, and you’ll know what I’m talking about.
Patterns are really just conversation short-hand.
If you’re new to web testing, you may have seen the Page Object Model mentioned, as short-hand. Basically it’s a pattern – put all the code that manages a single web page in one module. That’s it. It’s a fancy way of saying “how to organize your test code”.
I was part of a recent discussion about “Why do we consider the POM a very special pattern?”. If you’ve actually done some automation for a while, think about it – how many testing patterns, or really, named testing patterns, do you use?
The POM does seem special. But it really isn’t. However, special or not, it is a pattern you want to use.
What’s cool about the Page Object Model?
As I said, nothing special, really. But the pattern is built on top of software principles we know work, for what, about 50 years?
Here’s an example. My All-Time favorite registration application has two pages, the main page, and the “Thank You” page. Here’s the main page:

I can write the registration process test like this (using Playwright):

Everything is in there, and I mean everything. The test is bloated with details, and contains a mix of both pages. Although, some details are implicit – you need to check the “terms” check box to enable the button, and when clicking the Register button, we navigate to the second page. (But that’s for another post). Let’s focus on the maintainability – modifications in any of the pages – texts, structure, elements – will result in a need to change the test.
Here’s the first principle.
Separation of Concerns
If code A deals with page A, and code B with Page B, we probably want to separate the code into different modules. This means we know how to update both, with less side effects. Maintainability issues solved.
So here are the two page objects. The (partial) one for the “Registration” page:
And this one is for the “Thank You” Page:
See? No cross contamination. Next principle.
Encapsulation
Encapsulation is hiding the details of an operation inside the module from its clients. This way, your page handling code is inside the page object module, and the test doesn’t know anything about the mechanics. This way, if the mechanics change, but still perform the same functionality, everything’s cool.
Let’s look at the test, now updated to use the page objects:
What don’t you see here?
You don’t see locators. Our Registration page object can change, for example, from using a button, to a cell in a table, that looks and acts like a button. The test will not need to change. Or, I can change the code from using Playwright to Selenium and the test will not know about it. Almost.
Encapsulation hides details, and reduces coupling. Which is a good thing maintainability-wise.
Now, for the final principle.
Abstraction
The test calls methods on the page object. Currently the method spell out what they do – operating elements: “checkTermBox” or “typeEmail”.
But we can rewrite the test, by renaming the methods. We can describe their intent, without detailing how they do it. Like this:

Now, we can see not just element manipulation, but some meaning. While the meaning stays the same, the implementation can change (encapsulation FTW!). When the test fails, we can see the story, and connect it to user scenarios. If we want to dive in, we can do that too.
While we can make sense from the test in any form, the last one makes more sense to read, and helps more over time, long after we’ve forgotten that the term box enables the button. (You didn’t forget that, right?)
The Page Object Model is really not that special. It’s just short-hand for 3 good software principles. Ones we should be using all the time.
And if web automation is your thing, check out my Playwright workshop. It’s auto-liciuos.
1 Comment
Aaron Evans · March 25, 2025 at 8:19 pm
Hey Gil, great breakdown of design principles in the page object pattern.
So many people think it’s a framework or an automation method, but it’s just a way to apply those principles you mention, including encapsulation, abstraction, and separation of concerns.