A Conversation About Page Objects

Yesterday, I had the chance to meet the Aussie Uber Tester herself, Trish Khoo aka @hogfish who is stateside as of the writing of this post. Among the things that we discussed were automation patterns and how we use and implement them within the context of what we do. I started blabbing about how we started using the page object pattern even before the first selenium conference made it cool.

So, what is this Page Objects buzz and what is it good for?

Page Objects is essentially a coding pattern where you represent the pages under test as objects that you can interact with. In it's simplest form, a page object based test would contain two things, an element in the page under test and the actions that you can perform with that element. This pattern has proven to be very useful especially in the context that I'm in where I'm dealing with a hundred or so page types but the automated checks usually begin and end on the same page under test.

The question Trish posed before me was, how practical is the Page Object pattern if you are dealing with a complicated scenario that spans a LOT of pages. I was a little dumb founded. I didn't really think that far ahead. The most that I've dealt with in my case are 4 pages tops and even then, at that level, maintenance gets a little tricky, more annoying than tricky really.

Trish mentioned a pattern that she employs which to my understanding is behavioral based which I chose to dub as Persona Objects. I think she called it something else but I'm sticking with my name for the sake of this post. The focus of this particular coding pattern is no longer on the page under test but on the user or the persona the user takes when implementing a series of actions that spans multiple pages.

This question came at an opportune time because in the next few months, we are getting ready to look into how automation can help us test our CMS. If you know Drupal and familiar with Panels, Views and the Features module, you'll know that navigating through this system is almost a weaving art form.

A specific example I can think of is curating a specialized content-type that can be used for a never before seen page. From a CMS perspective you'd need certain types of data from multiple data sources, a list of pages in the CMS that you need to go through in order to create the content-type and finally, be able to validate the output data from CMS that our front end folks can consume in order to build the final page. To finish things off, we can also include a check for the resulting page.

I tried to layout a solution to the above problem and felt like the Page Objects pattern can handle the situation pretty well. Then taking a closer look at my scribblings, it seemed to me that after I'm done writing my script, someone would have to test it.

Yuck.

Good thing I have a couple more months to think about this and would love your input on how you do things on your end.