Testing with Page Objects: lessons from the trenches
Updated: Feb 6
This post is part of a series about Testing with Page Objects, make sure to check the full list.
The past four years I have been working at a frontend-intensive project which is mostly Java based. As such, there is a fair amount of Selenium-based frontend tests to verify the UI. This kind of tests have a reputation for being slow, unreliable, and, beyond anything, difficult to maintain. This is something that we briefly discussed in Continuous Delivery in Java, the book that I co-authored with Daniel Bryant. However, a fair amount of time has happened since then, and during this time I have identified a few design principles that can ease the task a lot. This is the first in a serious of posts where I want to share these lessons.
These principles are largely derived from Martin Fowler's article on Page Objects (very recommended), and it builds upon it. It also draws concepts from Atomic Web Design; it is true that Atomic Web Design applies to the design of the website, not necessarily to its testing, but once we start seeing a website as a collection of composable elements of increasing levels of complexity, we realise that the page objects that represent said website must also be designed in such a manner: if there are patterns in what you see, then there are patterns in the objects that represent what you see.
Because my experience is mostly Java and Selenium-based, these posts will use Java and Selenium samples. But make no mistake! These lessons are about design patterns, not syntax, and they can be easily applied to any other programming language where you need to perform browser-based testing.
I will be updating this post with links to the following posts as I publish them. Stay tuned.