Intro to Page Objects and Design Patterns in Selenium WebDriver

When writing automation scripts, object-oriented design patterns -- templates on how to structure the classes and objects created in Python or Java -- can be quite useful. One of the first design patterns automation engineers encounter are Page Objects, but there are others. Before introducing the talk, here's a quick history lesson on Patterns.

Pattern Languages in Object-Oriented Programming

As part of the Association for Computing Machinery (ACM), a new group called OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) was formed to address the concept of object-oriented programming which was becoming the dominant programming methodology.

At OOPSLA '87, the group's second conference, Kent Beck -- the future originator of "Extreme Programming", the precursor to Agile -- presented a talk that took the concept of architectural design patterns detailed in A Pattern Language: Towns, Buildings, Construction (1977) and applied them to software engineering.

"The search for an appropriate methodology for object-oriented programming has seen the usual rehash of tired old ideas, but the fact is that OOP is so different that no mere force-fit of structured analysis or entity-relationship methods will provide access to the potential inherent in OOP. In particular, neither of these methods address the user interface design issues that have obviously become of paramount importance. In addition, while E-R seems to be "object-oriented" it is not suited to the dynamic nature of objects as in Smalltalk and encourages the use of a global perspective while designing, a sure lose in object-oriented programming. 

"We propose a radical shift in the burden of design and implementation, using concepts adapted from the work of Christopher Alexander, an architect and founder of the Center for Environmental Structures. Alexander proposes homes and offices be designed and built by their eventual occupants. These people, he reasons, know best their requirements for a particular structure. We agree, and make the same argument for computer programs. Computer users should write their own programs. The idea sounds foolish when one considers the size and complexity of both buildings and programs, and the years of training for the design professions. Yet Alexander offers a convincing scenario. It revolves around a concept called a 'pattern language.' " (Abstract of Using Pattern Languages for Object-Oriented Programs, 9/17/1987 )

Related Links: 

• Oracle's Java Tutorials: Object-Oriented Programming Concepts: http://docs.oracle.com/javase/tutorial/java/concepts/
• Association for Computing Machinery: https://www.acm.org/
• OOPSALA History: http://www.oopsla.org/oopsla-history/ 

Design Patterns: Elements of Reusable Object-Oriented Software 

A few years later, at OOPSLA '91, at a session called "Towards an Architecture Handbook", Kent Beck and his partner in developing the "Extreme Programming" concept, Ward Cunningham, re-introduced to the attendees the concept of patterns. Four of the attendees, Eric Gamma and Richard Helm, Ralph Johnson and John Vlissides found they had common research, and grouped up to write a book, Design Patterns: Elements of Reusable Object-Oriented Software (1994). Listing everyone's name was difficult, so they were dubbed, "The Gang of Four".

The book became quite popular, and is still referred to over twenty years later.

"The first two chapters are an introduction and explain the reasons of the existence of design patterns, how they should be used, good and bad practices… Design patterns without rules to apply them are useless (as the original architectural patterns are useless without drawings skills). A practical example is the object of the second chapter. 

"Design patterns are exposed in a three parts catalog. Each pattern each described by a complete explanation, an UML diagram, the interactions between the pattern elements, as well as some implementation solutions (all solutions cannot be written, as it is language-dependent)"  - From Matt Eifelle's Book Review. 

Related Links:

• The ContentCreationWiki discusses in a very loose and informal conversational style  SoftwareDevelopment of the late 1980s and mid-1990s.
• The wiki also talks about the HistoryOfPatterns, KentBeck, WardAndKent, the ArchitectureHandBookWorkshop, the GangOfFour, their DesignPatternsBook, and the inevitable PatternBacklash. 
• Interesting sections on ObjectOriented programming, ObjectOrientedForDummies, EncapsulationForDummies can also be found on the wiki. 
• Design Patterns: Elements of Reusable Object-Oriented Software on Amazon.com
• Design Patterns: Elements of Reusable Object-Oriented Software in PDF Format

The Page Object Design Pattern

Taken from SeleniumHQ: Test Design Considerations:

"Page Object is a Design Pattern which has become popular in test automation for enhancing test maintenance and reducing code duplication. A page object is an object-oriented class that serves as an interface to a page of your AUT. The tests then use the methods of this page object class whenever they need to interact with that page of the UI. The benefit is that if the UI changes for the page, the tests themselves don’t need to change, only the code within the page object needs to change. Subsequently all changes to support that new UI are located in one place. 

"The Page Object Design Pattern provides the following advantages.

"1. There is clean separation between test code and page specific code such as locators (or their use if you’re using a UI map) and layout.

"2. There is single repository for the services or operations offered by the page rather than having these services scattered through out the tests.

"In both cases this allows any modifications required due to UI changes to all be made in one place. Useful information on this technique can be found on numerous blogs as this ‘test design pattern’ is becoming widely used. We encourage the reader who wishes to know more to search the internet for blogs on this subject. Many have written on this design pattern and can provide useful tips beyond the scope of this user guide. To get you started, though, we’ll illustrate page objects with a simple example" [ MORE ].

Design Patterns beyond the Page Object

Now that the basics are introduced, I can go into the initial reason for this blog post...

During last Fall's Selenium Conference 2014, there was a talk Design Patterns beyond the Page Object given by Derrick Kearney from Purdue University that I really enjoyed when I watched it online.

Description of the talk: Design Patterns beyond the Page Object

"In an age where the Page Object Pattern and Page Factory Pattern dominate web testing conversations, there is still a need to understand and apply the design patterns of yesteryear. Ideas from the Facade Pattern, Factory Method Pattern, the Iterator Pattern, the Object Pool Pattern, and the Decorator Pattern all find their way into the Page Objects we build to represent the increasingly complex widgets found on today's websites. 

"In this presentation, we take it back to the old school, looking at novel ways to apply classic design patterns, like those developed by the Gang of Four and Code Complete, to new screen scraping problems. We will investigate three common scenarios where using the typical approach to page objects can be inefficient or difficult, including filling in a web form, iterating over data in a list, and traversing iframes to communicate with widgets. We will explore how to improve upon the naive approach to building these page objects through the use of classic design patterns. Finally, we will formalize our findings into new patterns which can be applied to more general scenarios". [ MORE ]

Slides in PDF Format 

Slides in PPT format 

The recorded talk skips over the WebForm Design Pattern and jumps to the ItemList Design Pattern.

Here are one of the patterns covered...

ItemList Design Pattern

Let's say you have a list of items on a web page, such as a list of products returned from an Amazon.com an eBay search, or a search of support tickets. You don't want to hardcode the locators, but you want the ability to see the items in order, interact with the items in the list, and to search through the items.

Picture your search results as being in a Container, and each result as an item in this container. The items returned are sequential.

For this, you can create a Container class, where you can create different methods such as returning how many items are in the Container (num_items()), iterating from one item to the next ( creating a next() method ).

You can also create methods to get_item_by_position() and get_item_by_property() to search through this container.


-T.J. Maher
 Sr. QA Engineer, Fitbit
 Boston, MA

// Automated tester for [ 2 ] month and counting!

Please note: 'Adventures in Automation' is a personal blog about automated testing. It is not an official blog of Fitbit.com.