Easing Test Automation with the Page Object Pattern

[article]
Summary:
Everyone knows that GUI tests are brittle and costly to maintain, right? That conventional wisdom has broken down in recent years, thanks to better test libraries and frameworks, and better approaches to designing maintainable automated tests. My own current team felt our GUI tests, written starting in 2004, had a reasonable return on investment, but we still found we were spending more time than we liked to refactor and maintain them.

Everyone knows that GUI tests are brittle and costly to maintain, right? That conventional wisdom has broken down in recent years, thanks to better test libraries and frameworks, and better approaches to designing maintainable automated tests. My own current team felt our GUI tests, written starting in 2004, had a reasonable return on investment, but we still found we were spending more time than we liked to refactor and maintain them.

In 2009, I was inspired by Dale Emery's session on writing maintainable automated tests at Agile Development Practices West. I already knew that, as Dale pointed out, writing automated test code is no different from writing production code. We need to use the same principles of eliminating duplication and hiding essential details. The names we give our test scripts also matter.

My team applied Dale's techniques as well as we could, but felt there was a "smell" with our overall automated test approach. At Agile 2010, I attended an OpenJam session by Patrick Wilson-Welsh, where he demonstrated a "page object" pattern . He showed how to hide details and eliminate duplication with web page classes and page control classes "under the covers." When we apply the object-oriented techniques we use in our production code to our test code, our test code becomes much easier to understand and maintain. A "page object" is a test object that holds the details of all the elements on a web page that might be involved in an automated test.

I excitedly showed Patrick's work to my then-teammate Tony Sweets , who was officially our system administrator but also a developer who had always helped with our test automation. He started experimenting with the page object pattern.

Our team had other compelling reasons to start using Selenium WebDriver , and we wanted to apply the page object pattern. Our whole team, including Tony and other developers and testers, experimented with different frameworks, finally settling on Robot Framework . The developers and a system administrator on our team helped us understand the pattern, but we wanted to ensure that we got started on the right track in order to get a solid foundation for our tests. We brought in a coach who has a lot of experience using the page object pattern to help us with a customized three-day course, writing actual tests for our own application. We took the time to learn and experiment with good ways to apply this pattern.

Two months into using the page object pattern, I'm happy to report that frequent UI changes as we develop a new feature are no problem at all! For each change, we only have to change one file and all our automated tests continue to work. We're still learning and experimenting, but we’re confident our GUI tests will deliver a much better return on investment than before.

Practitioners such as Jeff "Cheezy" Morgan provide resources that give teams a head start in applying the page object pattern to automated GUI tests. Check out some ways that my own team is applying this pattern , and try your own experiments to see if you can create UI tests that are less brittle and cost less to maintain by applying the page object pattern. 

User Comments

2 comments
Jim Hazen's picture
Jim Hazen

Interesting how the Selenium community is now catching up in the practice of using a 'component' type approach to automation for GUI. The practice of abstracting the individual page & object code into its own code module has been around a long time. This along with writing custom functions or methods for the objects has also been around a long time.

Both Component and Keyword automation methodologies, or a combination of both in Hybrid approaches, prescribe to an approach of modularizing the code and working towards robust and reusable code in automation.

The problem with GUI automation has always been one of ignorance by the tool vendors and management that automation really is a software development project itself. Thus must use the same methods and technical staff (with appropriate skill/knowledge level) as development for the automation work. It has always been sold/seen as a Record/Playback method that any monkey on a keyboard can do. This fallacy is what has caused GUI level automation to fail.

Conversely, the one thing I give Agile and Opensource tools like Selenium credit for is finally pushing the idea that automation is best done by people with developer mentalities. But as part of this they need to understand testing itself. What needs to happen is a 'hybrid' type person is doing this work. They understand testing, but also know how to code and how to build software (design and construction for maintainability).

GUI level automation has always had a problem with the 'Automagic' snake oil sales job. Finally it seems this is changing.

The design pattern (approach) for Page Object is not new, but finally getting the acceptance and implementation needed to help make automation more robust and maintainable.

July 23, 2012 - 12:02pm
Curtis Stuehrenberg's picture
Curtis Stuehrenberg

I'm curious about why you went with Robot. Can you elaborate on why you chose that specific framework versus going all the way with a framework like Cucumber which is open source but has a much larger and more active user community or Twist which is proprietary and so has vendor support?

July 24, 2012 - 10:42am

About the author

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03