In Page Object pattern, aren't we creating over-specialized methods than generalized re-usable functions?

Question

Background: In the Selenium UI automation we all have been using Page Objects pattern as the "Best Practice" for years. In Page Objects "methods" are tightly coupled to pages instead of generic context free functions. As per my observations, 70-80% Page objects methods code are not directly reusable in other web applications as every page object method is highly specialized to a specific page in a given web application.

We can also gain the same level of abstraction (if not better) by simply defining an objects collection (Object repository) and a set of well-defined actions/utility functions to operate on it.

Then what exactly is the point of using page object pattern where we can use simple functions which can be re-used in different contexts. So, aren't we over coupling things in page objects?

Dilemma: Fundamentally, there is a handful of UI operations that we can perform in any UI automation. When we are defining methods in the context of a page, aren't we creating over specialized "methods" than generalized "context-free functions" ?

Example: The page object method like "click submit_user_button" which is specific to a page and might not be directly re-usable even in same application in other pages!

I strongly think, this is costing us flexibility=>reusability=>maintainability?

Answer 1

Isn't that what pageObjects are in essence: A description of the UI elements on a Page and how you can interact with them.

Now when writing tests you often interact with multiple elements in a certain way to achieve a workflow. Now if multiple tests use the same workflow it might make sense to move the combination of workflow-steps also into the pageObjects so other tests can re-use it. I wouldn't start with this, just keep it DRY.

Splitting all the UI elements and its interactions into pages and workflows just make it easier to read, understand how and when to use them.

I really don't get how this is overcomplicating things. Creating abstractions, decoupling and storing this in files of around 100 lines is what programmers do for a living.

When creating pageObjects don't over-engineer them from the start. Keep the YAGNI principles in mind.

What I like about well done page objects is that you decouple the driver of the browser from the tests. The tests interact with the pages, the pages with the driver. The tests don't know the driver. This means you could switch the driver from Selenium to Cypress without changing the tests in theory.

Answer 2

Page objects work well in smaller sites where there is little to no re-use of fields because the coupling effect isn't significant enough to cause major issues - there will always be challenges finding a balance between readable tests, DRY, YAGNI, and SOLID.

I've found that once the application is large enough it's better to work in terms of input type objects, so that the test code is passing the locator information as well as any data to be entered.

This massively simplified my test code: I have an object to handle edit-type inputs, another for clickable fields (buttons, links, and so forth), another for checkboxes, one for dropdowns, and so forth. This allows my page object to be a single generic object that calls methods like FindAndClick(string id), FindAndEnterText(string id, string text) etc. (Then I data drive the test so that the ids, text etc. are read from a CSV file by the test harness).

Answer 3

The term PageObjects has become greatly over-used (including by me).

To reset:

We have element locators.
Sometimes our element locators also have an action (such as click) with them.
Some element locators are at the page level but others can be considered to be at fragment, frame, workflow or domain specific grouping levels

These locators are then basically accessed in two ways - directly at the top layer of the test script, e.g. click user_submit_button or by your custom DSL which might be submit_user_form and then the function submit_user_form itself has the line click user_submit_button and user_submit_button is defined at the next lower, page object, level.

In either case the 2 key roles that the page object serves are:

• reduce errors due to duplicate definitions of the same element
• name the object to make it more readable and easier to maintain

You want the code to read more like

click submit_user_button

and not something like

click(find('div.users span#inputform button'))

Yes we are creating quite specific and selective and not general functions here but in this case general functions is simply not the only goal in writing this sort of specific test code. We are making code maintainable, that is the goal. I've seen code that didn't use Page Objects and it gets ugly looking fast.

Answer 4

As it seems to me, Page Objects does not introduce abstraction to the code since when you define a page object you do that for a specific element of the page. I would also not oppose Page Objects to Object Repository since basically object repositories are intended to store page objects.

When I use Page Object pattern, I can see the biggest value in possibility of combination of that architectural pattern with OOP conceptions and instruments that programming language provides.

For example you can define page objects bound to a class and then extend that class by adding other objects / hiding existing objects. This will help you follow the implementation of your application since this is the common practice to reuse UI components in different places of the application and to extend the components capabilities (what you can address with inheritance when use page object) for example depending on what the role a user has.