Page Objects Design Pattern
A simple task is easy to perform. But, the effort multiplies exponentially when the simple task is to be performed repeatedly.
There is no dearth of monotonous and mechanical web based tasks in the world. Such monotony makes a human lose interest in the task as well as his/her job itself.
As soon as boredom meets creativity, innovation is born.
A simple google search to create a web automation tool will lead to results like Selenium browser automation tool and services built on top of it. As one goes further, he/she can’t escape the bombardment of phrases like Quick start, Easy to use, Minimal effort required etc.
An experienced coder is generally wary of these phrases. Experienced coders tend to believe that a piece of code is read more often than it is As one starts looking for long term reliability and maintainability, search results start showing the page objects design pattern among other known design patterns and guidelines.
An excerpt from Martin Fowler’s article on page objects:
“A page object wraps an HTML page, or fragment, with an application-specific API, allowing you to manipulate page elements without digging around in the HTML.”
In most simple terms, page objects provides the developer with every functionality a human and see and interact with the page. It acts as a decoupling layer between the developer and the HTML page itself.
Most part of a browser interaction script is dependent on the UI of the web page and with rapid modern enhancements in not only designs but also the functioning of the UI elements, it is very easy for a browser automation script to lose its relevance. Page Objects help immensely in maintaining the code and phenomenally increases the shelf life of a browser interaction script.
Misleading Term: Page Objects
The term Page Object instinctively makes a person imagine that a page object should represent the entire web page. This is untrue.
A page object can represent a UI component as small as a text box or a button.
Page objects as a design pattern is still relatively new and does not manage to solve all the problems a developer might face while writing a browser interaction/automation script. But it is a step in the right direction to start looking for solutions. It is also probably the only design pattern that deals with browser interaction.
There are healthy conflict of ideas and debates in the community regarding implementation of page objects. These conflicts may be generic or use case specific. But since one of the major aims of this design pattern is to solve the maintenance problem over a period of time, the prevalent best practices regarding its implementation can only be established after a long period of time.