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.
