Screenplay Pattern – a SOLID alternative pattern to Page Objects

This blog is based on the talk presented by Antony Marcano on Screenplay pattern, in Selenium conference 2016. I have also looked into some tutorials online (listed at the end), which also contributes to some contents below and my better understanding of the pattern.

Screenplay pattern (formerly known as the Journey Pattern) is a design pattern to write acceptance tests which is based on SOLID design Principles. It was devised by the speaker, Mr. Marcano himself in between 2007 – 2008 and was refined later by Andy Palmer and Jan Molak. Marcano starts the talk by stating the pain points of Page Object pattern and proceeds with stating how Screenplay pattern can help to solve those problems. He also presents some test codes written using Serenity which adopts the Screenplay pattern and JUnit. In the sections below, I will explain concepts of SOLID principle, its usage in Screenplay pattern, details about the pattern and motive behind its adoption. However, I won’t be explaining how to actually write tests using screenplay pattern, as there is a very good blog post on how to do that here.

SOLID is a part of Object Oriented Design, specifically:

Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Substitution Principle
Dependency Inversion Principle

When writing acceptance tests using Page Object pattern, for each web page there is corresponding Page Object which contains web elements of the web page and actions, each elements performs. Hence, with each new element and action, the size of the class increases. This often leads to an anti pattern called “Large Class” which is a violation of some SOLID Principles which are SRP (Single Responsibility Principle) and OCP (Open Closed Principle). SRP states that a class should be responsible for only one responsibility. OCP states that a class should be open for extension but closed for modification. Screenplay pattern adheres to these principles and states that for each action that an actor can perform, there should be a separate class. This means for each method there will be a method class. This leads to many smaller classes rather than few larger classes making them easier to read and maintain.

Screenplay pattern focuses on writing ATs, concentrating on what a user can perform rather than how. Mr. Marcano got this idea from a user centric design principle which focuses on the answering following questions when trying to model a problem:

Roles: Who is this for?
Goals: Why are they here and what outcome do they hope for?
Tasks: What will they need to do to achieve these goals?
Actions: How they complete each task through specific interaction.

According to this framework, while writing tests one should not be thinking about modelling the application or solution or implementation but should be thinking about what the user can do and achieve. When thinking from that perspective, in the real world scenario, above questions can be interpreted as following:

Roles -> Who -> As a library member
Goals -> Why -> Scenario: Find a book
Tasks -> What -> theMember.attemptsTo(Search.bookWithTitle(BOOK_TITLE))
Actions -> How -> Enter.the(bookTitle).into(searchBookScreen.searchField) + Click.onThe(searchBookScreen.searchButton)

As seen above, there is clear distinction in between ‘tasks’ which is declarative and ‘actions’ which is imperative. Screenplay pattern provides this level of abstraction making it easier for the team to write layered tests more easily.

In Screenplay pattern, roles are performed by Actors. Actors have abilities such as ability to browse the web using the browser. They perform business focused tasks to achieve their goals such as “Search for a book”. Actors can also ask about questions about the state of the application, such as checking the state of the result screen. These can be represented as:

Figure 1. Screenplay pattern [1]

As seen from the figure above, the screenplay pattern is focused on the actors who have abilities to perform tasks, enable actions and ask questions about the application and its elements to achieve their business goals. In serenity, these can be represented as

Actor james = Actor.named("James");
James.can(BrowseTheWeb.with(hisbrowser));

A good tutorial on how to apply screenplay pattern with Serenity framework can be found here.

To conclude the blog, in my opinion, both screenplay pattern and page object pattern has their pros and cons. Screenplay pattern does have benefit of adopting SOLID design principles but it might lead to creation of hundreds, if not thousands, of method classes for a complex application, which should be reusable and maintainable. Even though, with this pattern, creation of web page objects is eliminated; we need to identify the web elements for the actions and assertions. In addition, it might take quite a lot of effort and discipline to write the tests with well designed tasks and actions. Thus, like any other design pattern, adoption of screenplay pattern depends on the scope of the project and attitude of the team.

References:

Leave a Reply Cancel reply