Gojko Adzic

Although Selenium is an essential trace element, it is toxic if taken in excess. That is what Wikipedia has to say on the chemical element Selenium, but pretty much sums up my feelings about the web testing tool of the same name as well. I like very much how easy it is to implement web tests with Selenium, but I’ve seen so many teams shoot themselves in the foot by misusing it and wasting a ton of time on writing and executing tests that simply got thrown away on the end. The Page Object pattern, popularised by Simon Stewart with WebDriver, seems to be the universally accepted best practice to manage UI tests efficiently and the preferred way to implement Selenium tests. However, at the recent CITCON Europe conference in Paris, Antony Marcano spoke against this and offered an alternative.

One of the biggest issues with UI tests described at the task level (such as click there, type this etc) is that they are very brittle and hard to understand. Too many details in technical steps make it hard to see the big picture, so tests work nicely as a regression check but once something fails it is hard to figure out what exactly went wrong. They are also bound to a particular UI design, so when the design changes, lots of tests break. Selenium works on the technical task level and tests written for Selenium frequently fall into this black whole. Once the design is changed, you might as well do everything again from scratch.

Instead of writing tests at the technical task level, the Page Object pattern suggests creating one more level of indirection and describing business functionality of pages with objects (eg search for customers, submit registration form) and then implementing individual methods of these objects with Selenium. Tests are then written with the page object methods, which make them much more understandable and easier to maintain. Once the UI changes, we can reimplement only the relevant methods of Page Objects making the effects of changes relatively contained. Tests themselves don’t need to change. Similar ideas are implemented by xUseCase recorders and Domain-Specific Testing Languages in Selenium (see Mickey Phoenix’s Agile 2008 presentation).

Marcano said that page objects focus on the wrong thing. Taking ideas from interaction design, he suggested that it is natural to think about functionality on three levels — goals, activities and tasks:

1. Goal: Buy a book
2. Activities: Add the following items to the cart,…
3. Tasks: click search, type in book name, click book image, click Add to cart…

When thinking about web site functionality, people don’t think about pages but about activities that span multiple pages. Focusing on goal oriented cross-page activities instead of page oriented functionality makes tests more natural, easier to understand and maintain. Instead of Page Objects, Marcano suggested implementing activities with Selenium and then composing tests from activities. One more significant benefit of this approach is that activities aren’t baked into the user interface, unlike objects representing web pages, so the same test definitions can be kept for testing below the UI with different task implementations.

Get notified when I post something new - subscribe via RSS or Twitter!

Trackback URI | Comments RSS