When automating tests for web pages, it is a common approach to use the PageObject pattern. It helps you to extract away the technical aspects of web testing, and lets you focus in your test cases on the test steps the web test actor needs to perform.
We have used this approach in a project, where web pages are assembled out of so called modules. You have for instance a header module, a footer module, some text modules, and so on. Let’s call these modules sections from now on. The sections are configured in a CMS.
When using here page objects for a complete page, you get a lot of code duplication, since sections are used on several pages (like the header). Thus, our first approach was to use page objects for the single CMS sections, which just encapsulate the data needed for a given section. This is also very close to the approach suggested in the pattern. This “section object” approach did solve the code duplication issue, but had several drawbacks in our setup:
- To write a test you needed to know the CMS sections which are on the page. This was not always easy since there were very many sections available. The whole section concept was not clean enough to allow for an easy access.
- Sometimes the same section appeared several times on the same page (like the login section). Using a simple section object did not allow for a specific access to the sections.
To deal with this issues, my colleague Robert Bossek from QualityMinds developed an extended approach for section objects, which solved these issues.
The main ideas is, that we have section objects which all have a specific context. This context is commonly a CSS locater prefix, which allows to find a specific section on a page. Furthermore these sections are then assembled together on a “real” page object, which represents the given page. To do so standard OO techniques are used. Altogether, you get a modular approach which avoids code duplication, is as easy accessible as the standard page objects, and allows for several sections on the same page. This was a very nice result!
Robert presented this approach at the First Munich Selenium Meetup.
Here are the slides:
We have also extended the approach to allow for specifying BDD scenarios. We have implemented everything in our preferred web test automation framework Codeception.