I'm looking for canonical answers explaining the importance and advantages of the Page Object Model design pattern, specifically answers that I could point to for people who claim the pattern is unnecessary or outdated, or who claim to offer a "better" alternative. We have a lot of answers scattered around the site but nothing that could be considered canonical. Here are examples of the better ones I've found, but they are either quite old or only address one aspect of the question:

Some common counterarguments that the answers should address:

  • The Page Object Model involves too much "ceremony"/YAGNI.
  • You shouldn't be using your UI to set up state--just use the back end to do that and then test your UI from there (example: https://stackoverflow.com/questions/50685302/page-object-pattern-in-cypress - I believe this has some merit but I don't believe it completely eliminates the advantages of having Page Objects).
  • I'd list the record-and-playback pitch but I think the last question in my list above covers it pretty well. I'm sure others with more experience have heard other arguments as well, which I'd appreciate their responses to.
  • POM leads to excess code and maintainability issues

Answers should also provide some guidance on how to implement the POM pattern to avoid common pitfalls.

  • Created in response to Kate's answer to my question on meta: sqa.meta.stackexchange.com/questions/535/…
    – c32hedge
    Commented Jan 2, 2019 at 16:48
  • 2
    I believe this question is improperly stated from the beginning. The way how you convince "someone" depends on who is that "someone". Either it is a business owner or a dev lead or a tester, etc.
    – Alexey R.
    Commented Jan 2, 2019 at 23:18
  • Who is convincing whom in what context? Commented Jan 3, 2019 at 1:49
  • @AlexeyR. and VishalAggarwal yeah I struggled a bit with how to word it. My intention was to have a definitive single link to be able to point people to when attempting to justify the use of POM, that would ideally address some of the common arguments against it versus just defining it in a vacuum. Open to suggestions or edits to make it better.
    – c32hedge
    Commented Jan 3, 2019 at 15:25

1 Answer 1


Page objects are a classic example of encapsulation - they hide the details of the UI structure and widgetry from other components (the tests). It's a good design principle to look for situations like this as you develop - ask yourself "how can I hide some details from the rest of the software?"


I can't see how anyone can be against this. If you have a better alternative to "hide some details from the rest of the software" use it. Similar to the DRY principle it is common sense in most situations.

The problem with the Page Object Model is that it is mostly documented as more than just simple page objects. The simple page objects are where the value lies. The complexity of PageFactories and other documented bloat is what was valuable to some person at some time, but is now presented as the way to build Page Objects as a Model.

So simple Page Objects are good practise and complex Page Objects Models should be situational.

For illustration here a simple page object, for this simple test in C#:

// Arrange
IWebDriver driver = new ChromeDriver("./");
Google Google = new Google(driver);
// Act
int results = Google.Number_Of_Search_Results_For_Query("pageObject");
// Assert

And the page object:

class Google {
    private IWebDriver _driver;
    public Google(IWebDriver driver) {
        _driver = driver;

    private void Open() {

    private void Search(string q) {
        _driver.FindElement(By.Name("q")).SendKeys(q + Keys.Enter);

    public int Number_Of_Search_Results_For_Query(string q) {
        string results = _driver.FindElement(By.Id("resultStats")).Text;
        return Int32.Parse(results.Split(" ")[1].Replace(".", ""));

Now as more and more tests start to using the page object you can decide to add complexity. E.g. return a Search Result List page or make the private methods public.

Most application start simple, so should their tests. Evolve complexity as the need arises.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.