Problem: The page object pattern is not yet understood by the average tester.
To get the most out of this post, please read this post and then read at least one of the articles listed in the Holy further reading, Batman! section below.
Why this post?
There are many ways to write and maintain GUI automation tests. The most common GUI automation design patterns that I have seen are linear blobs of code with no methods, the facade pattern and the page object pattern. Testers usually begin by writing one off scripts with linear code that are not organized into methods. Most testers then automatically graduate to using the facade design pattern – even if they do not know the name. In my experience, only a small percentage of testers graduate to using the page object pattern. This post is an attempt to introduce the page object pattern to more testers.
NOTE: Bolstered by the positive reception to my post The art of writing xpaths, I have decided to take the creative route again. This explanation of page object pattern involves no code, no tests and very few references to web pages under test.
Background on page object pattern
I am unable to find the exact origins of the page object design pattern. I am grateful to any reader who can enlighten me on the topic. I first heard of the page object pattern when trying out Selenium Webdriver. Martin Fowler’s excellent piece on the topic of page objects seems to suggest that while the pattern has been around for a while, the name and its use in the testing community took off as Selenium Webdriver gained popularity.
How would you describe Batman?
I would describe him as a superhero
a) who wears a black cape, a bat shaped hood, some super cool weapon-ized gloves, a utility belt and a skin tight bullet proof body suit that has a bat symbol on his chest.
b) whose favorite moves are stealth attacks, deception and trickery, throwing batarangs, striking and counter-punching.
In my description of the caped crusader, I separated Batman’s looks from his moves. You probably found that reasonable and intuitive. Similarly, testers who have written and maintained large amounts of automated GUI tests, have learnt that separating the looks of the webpage from the actions of the webpage to be very useful. The page object design pattern represents each page of your web application as one or more objects. You separate the GUI elements from the page actions themselves. The looks of the page include things like text boxes, drop downs, radio buttons, etc and are identified by locators. The actions of the page include things like submit form, fill in text field, etc and are modeled as methods. This helps reduce code duplication and allows for easier maintenance of tests. And that’s the gist of it.
The next time you are struggling to understand or implement the page object pattern, think of Batman. May be even hum to yourself na na na na na na na na na Batman!
NOTE:I like Batman because I think he would make an excellent chess player …if he put his mind to it. Instead he chooses to save Gotham. Time to re-examine your priorities, @Batman!
UPDATE: Chess.com asked the important question and it looks like Batman is the winner by a margin!
Holy further reading, Batman!
Team Qxf2 have hand selected the following as the best pieces on the topic of page object pattern:
1. Martin Fowler on Page Objects: http://martinfowler.com/bliki/PageObject.html
2. This excellent piece by Adam Goucher: http://pragprog.com/magazines/2010-08/page-objects-in-python
3. Selenium wiki: https://code.google.com/p/selenium/wiki/PageObjects
Did this piece help you get started with page objects? Leave your feedback in the comments section below.