How would you convince someone that the Page Object Model pattern is important?

Question

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:

• What is page object modelling? and Why is it so important?
• In Page Object pattern, aren't we creating over-specialized methods than generalized re-usable functions?
• What are the trade-offs of using page objects instead of a collection of functions in UI automation?
• How you decide the right level of function abstraction in Page object model?
• How do I convince someone who's bought the Record-Playback line that object oriented framework is essential?

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.

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?"

https://martinfowler.com/bliki/PageObject.html

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
System.Console.WriteLine(results);

And the page object:

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

    private void Open() {
        _driver.Navigate().GoToUrl("https://google.com/");
    }

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

    public int Number_Of_Search_Results_For_Query(string q) {
        this.Open();
        this.Search(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.