The Trouble with Page Objects – Things you always knew were wrong but couldn’t explain why

PageObjects have some common problems that many people see but not everyone can explain. Over time they can become harder and harder to maintain. In some cases, they become a tangled mess riddled with deep inheritance hierarchies. How can this happen?!

PageObjects provide an easy-to-follow, simple structure that avoids early maintenance issues. But, they break some key OO design rules, making maintenance more difficult over time. This can result in flaky tests. PageObjects were introduced to help test-developers avoid mistaking flaky tests for problems with Selenium. It was a useful first step, so why did we stop there?

In this session you’ll learn about the SOLID design principles that PageObjects disregard. You'll see why this leads to problems. You’ll see how and why PageObjects benefit from refactoring to SOLID design principles. Finally, you’ll meet the Screenplay Pattern; an alternative that can save you the effort.

 
2 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

The talk will include several easy-to-follow code examples, telling the story as follows:

  • Some history on Page Objects
  • What are the common problems people encounter?
  • How do they become harder and harder to maintain?
  • A typical PageObject example
  • What is SOLID and why does it matter?
  • What are some common ways that PageObjects violate SOLID principles?
  • How to refactor PageObjects towards SOLID principles.
  • How a task-centric domain model increases flexibility.
  • The Screenplay pattern – PageObjects refactored.

Learning Outcome

  • Non technical attendees will recognise some of the challenges their colleagues face and have takeaways they can use, such as the task-centric domain model.
  • Beginners will learn what to expect as their test projects grow and where to begin when they encounter problems.
  • Intermediate and beyond will understand the common problems of using the Page Object Model in greater depth and some practices to deal with them.
  • Everyone will enjoy an energetic and fun presentation that for some may challenge the status quo in an enlightening way.

Target Audience

Testers, SDETs, Developers, Business Analysts, Architects

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Lisa Crispin
    By Lisa Crispin  ~  1 year ago
    reply Reply

    Like many (if not most) teams, our team was suffering from flaky Selenium tests. Antony's writings on the problems with Page Object and the benefits of taking SOLID steps to a Screenplay/Journey pattern have directly benefited my own team's BDD and UI test automation efforts. It is a crucial area and I do wish this were a longer session. As a keynote, though, it's a potential game-changer for a lot of people who are using Page Object and other patterns but still feeling pain. This is a big new development in automated web testing with Selenium and can transform a team's ability to create reliable Selenium tests.

    Test automation code is code, and deserves the same care and attention as production code (if not more, because these tests are also our living doc). Antony is an inspiring presenter who knows how to engage a diverse audience and explain complex new concepts. He definitely challenges the status quo, but in a positive way - he'll get participants excited about experimenting with these new approaches, and will be capable of doing so.

     

  • AntonyMarcano
    By AntonyMarcano  ~  1 year ago
    reply Reply

    Following feedback I've reduced this to a 45 minute keynote. I think it should be longer but am open to change.

    It is proposed as a "keynote" but could be given as a "talk".

    It is recommended as a keynote because the message is an important one. Too many teams continue to use PageObjects as-is without realising that their code can be far easier to maintain. This is because page objects break key OO design principles. This is ok as a place to start but isn't where it should end.

    Having introduced this notion to teams, once they refactored, their resulting code was "the easiest code they've ever worked with".

  • Anand Bagmar
    By Anand Bagmar  ~  1 year ago
    reply Reply

    Hi,

    Are you sure this is a 90 min talk? Seems like a very long talk related to Page Objects. Can you please add some timings to your session structure to get better idea about the spread of the content?

    Also, is this correctly submitted as a Keynote? Can you please recheck the submission?

    Lastly, a suggestion - maybe you could focus the talk on only the Screenplay pattern and its uses in specific contexts - since that is not a very common pattern - it will be quite helpful for the attendees.

    • AntonyMarcano
      By AntonyMarcano  ~  1 year ago
      reply Reply

      Hi Anand,

      Thanks for the feedback. How long would you like a keynote to be? If it is 45 minutes, then I can trim it down considerably, however, I think an hour is best (including audience engagement and questions) but a 1 hour session wasn't available as an option in the submissions.

      The reason I'm proposing this as a keynote is because it is a somewhat controversial yet insightful and ultimately inspiring topic – once people hear what I have to say... there will be a lot of discussion.

      PageObjects are used far and wide in the Selenium/WebDriver community and are the staple drop-in solution for most projects I encounter. They have become such a standard approach that many people overlook the fact that they actually violate some key OO principles that any reasonably good test-developer will know – we've just become blind to it. These principles (from SOLID) contribute directly to the maintainability of code. There are many teams experiencing maintainability issues that they have simply become used to, so they continue to use PageObjects not realising that their work could be much easier and as a result could deliver more value to their projects.

      In the talk, I take the audience on a journey where they begin to question the staple use of page objects beyond basic training-wheels. Each time I talk to people about this, as I hand-hold the listeners through the principles, illustrate why and how you'd refactor page objects to address those principles; the code and the listener arrives at the same realisation – that PageObjects don't make as much sense as they once thought and find themselves naturally evolving their mental-model towards a different way of doing things.

      Simply by refactoring to these principles and with a little Domain Driven Design thinking, the same model emerges – hence the discovery of a pattern. I happen to refer to this pattern as the Screenplay Pattern. The talk literally refactors the mental model of their application, subsequently restructuring the support code around it – resulting in them moving on from PageObjects and towards the Screenplay Pattern.

      So, PageObjects are the context and refactoring them is the journey towards the Screenplay Pattern.

      I have delivered highly rated keynotes in the past, voted best Keynote at the 2015 Agile Testing Days. I am confident that this topic will offer some powerful 'ahaa' moments, inspire debate, conversation and will advance the state-of-the-art in how people think about their test-code using Selenium. Given the number of talks on PageObjects proposed, I'd recommend this as a closing keynote or to be near the end of the conference.

      I would love to hear your advice on how long a keynote will be at this conference with your thoughts and feedback on these clarifications.

      Kind regards,

      Antony


  • Liked Andy Palmer
    keyboard_arrow_down

    Robot Handles - Giving Selenium a Helping Hand

    Andy Palmer
    Andy Palmer
    RiverGlider
    RiverGlide
    schedule 1 year ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    By far the most common way to use Selenium to interact with an application is to code tests that have intimate knowledge of the underlying application. This is simple, but brittle. Others may try to make the test code intelligent, leading to a very complex testing framework. There is a middle ground.

     

    Imagine that we are building a robot to move eggs. A simple robot can deal with identical eggs, but is brittle as soon as new eggs are introduced. An intelligent robot could adapt to variations with sensitive touch sensors. Or, we could use egg-holders with a handle on top. Now all we need is a simple robot that understands handles. If we then want to move something instead of eggs, we just need a new holder – the handles and the robot remain the same.

     

    In this session you’ll learn the metaphor of Robot Handles, discuss ways that we can add meaningful interaction metadata into the application as we build it, and demonstrate how that can be just as helpful for humans as it is for robots