Flaws in the Page Object Model?

Question

I read this article about flaws in the Page Object Model/POM, authored by a lady at ThoughtWorks - https://blog.getgauge.io/are-page-objects-anti-pattern-21b6e337880f

She says that POM leads to excess code and maintainability issues. For example, she goes against the general recommendation that Page Objects/POs should return other POs - See the content under the heading "Method chaining".

Are these arguments sound ? Are there any genuine flaws in the POM ?

Answer 1

I think if you stick to simple PageObjects as described by Martin Fowler it is fine. It should be a simple abstraction to keep your test-code DRY, reusable and increase readability by using page-methods that describe behaviour of the page/view.

The linked article is mainly about issues with Page Factories and thinking PageObjects have to return another Page (they don't, but sometimes it is very handy!). Personally I have never seen a use for PageFactories, they do magic stuff I don't need, are verbose, etc.. Nor do I see the need for an extra Step layer that the suggested Guage adds. For me that is similar overhead and introduces other pains.

Just keep it simple, and only add complexity when you need it.

Answer 2

I will not go into the details of what the problems are regarding Page Objects, there are lot's of articles on the net by people who put in more thought than me. From my experience though I would go with https://johnfergusonsmart.com/beyond-page-objects-liberate-chains-ui-think/ in saying: page objects are fine but another level of abstraction is helpful like the Screenplay Pattern

In short: yes, the arguments are sound, there are flaws. Page Objects still have their reason to exists for learning and as stepping stone to better models.

Answer 3

The conclusion that

She says that POM leads to excess code and maintainability issues.

is wrong.

Page Objects is a a concept that can be implemented in many ways.
They solve two simple problems:

• They reduce duplication
  DRY is usually good

• They name stuff
  One of the two hard problems in computer science

They reduce maintainability issues - the exact opposite of one of the points you list

I think a simple example will show both:

I will use pseudo-code

Without page objects

find ('div#main_content input#name').click   #for focus
fill_in('div#main_content input#name'), with: 'Bob'
expect(find('div#main_content input#name')).to have_Value 'Bob'

With Page objects

name = div#main_content input#name # probably done in a setup file

find(name).click
fill_in(name), with: 'Bob'
expect(find(name)).to have_value 'Bob'

The second seems much more readable to me.
Also, although both would need to be changed if the locator changed, in the second case this change is only in one place, whereas in the first case the locator in 3 different places would need to be updated