Screenplay pattern for Automation Test projects — An alternative to POM
Abstract — Literature and case study shows a predominance of Page Object Model as the de-facto pattern when Automation Testing Frameworks are implemented. Most of the time, we all agree on the benefits and how we should define it but sometimes we do not consider other factors that could challenge this approach.
The aim of the article is not to bring down the model but to provide another vision of test automation patterns and how they can help successfully when unexpected scenarios arise or when project conditions are not desirable.
Why is it a good idea to use design patterns in our Automation projects?
Automation testing is a process of developing software to test software. Hence, the test patterns are loosely similar to design patterns that are used in software development. The most challenging aspect in test automation development has always been the code maintenance. A lot of test automation projects have drowned or were scrapped due to the inability of the frameworks to cope up with the growing codebases and constantly changing features. In order to keep the maintenance cost low, the automation engineers should strive to minimize the code that they reinvent or create from scratch by using existing functionality for common, generic, or repeated operations[1].
Page Object Model
A Page Object is an object-oriented pattern that serves as an interface to a page of your AUT[2], encapsulating the page elements and abstract the actions to be performed in the UI. The benefit is that if the UI changes for the page, the tests themselves don’t need to change, only the code within the page object does. Subsequently, all changes to support that new UI are located in one place[3]. In summary Page Object Design Pattern provides the following advantages:
- There is a clean separation between test code and page specific code such as locators and layout.
- There is a single repository for the services or operations offered by the page rather than having these services scattered throughout the tests.
Is POM[4] the best solution for all the scenarios or applications? When complex and large scale projects are faced we start to see some challenges like:
- Costs on refactors and updates increase due to the maintenance of large classes as they break the OO design principle.
- Development of a POM framework for multiple pages and complex components is equal to any application development thus the team should be highly knowledgeable in programming best practices.
- Page Object Model is not a generic model and it’s specific to pages/screens based applications.
Page Objects are a good place to start for teams not familiar with patterns and design principles used by proficient programmers (e.g. SOLID) but the importance of bringing strong technical skills to the team should be considered early on in a project to avoid these challenges[5].
Screenplay pattern
The Screenplay Pattern is an approach for writing high-quality automated acceptance tests based on software engineering principles such as:
- Single Responsibility: A class should have only a single responsibility.
- Open-Closed: A software module should be open for extension but closed for modification
- Effective use of Layers of Abstraction: Hiding the working details of a subsystem, allowing the separation of concerns.
It encourages healthy testing habits and well-designed test suites that are easy to read, easy to maintain, and easy to extend, enabling teams to write more robust and more reliable automated tests more effectively[6]. It was introduced by John Ferguson Smart as part of his Serenity BDD framework in order to center the design pattern on the user interactions rather than the application pages.
Taking the concepts from the SOLID[7] principles the framework design is broken down in the way a user interacts with an application into goals, tasks and actions.
As we already defined the users are the main concept of the pattern and they are surrounded by different features that help them to execute use cases:
- An Actor is a user of the application and it has a certain number of Abilities, such as browsing the web or to query a restful web service.
- An Actor performs Tasks and each of the them is made up of one or more Interactions taking into consideration that those interactions need to be compatible with the abilities of the current actor. These interactions are directly affecting the state of the application
- Actors can ask Questions in order to validate actions and goals.
Another main focus of the Screenplay pattern is the production of highly readable test code. Let’s take a look at how these concepts are integrated with some examples using Java language:
Define a new actor:
Actor james = Actor.named(“James as IT professional”)
Actor has Abilities:
james.can(BrowseTheWeb.with(hisBrowser))
Actors perform a Task:
james.attemptsTo(SearchCareers.forPathWith(MOBILE_DEVELOPMENT))
Tasks are made up of Interactions:
Enter.theValue(theCareerPath).into(careerPathScreen.searchPath)
Actors ask Questions:
james.should(seeThat(theCareerItems, hasItem(theCareerPath)))
Case of Study: Single Page Applications
We are going to review with a simple example of the mental process to design automation testing frameworks using BDD and SOLID principles.
In general web applications are defined as a set of linked web pages with interactive components allowing users to make predefined actions and transactions. Nowadays these applications are being transformed to behave like desktop applications and described with a new terminology: Single Page Applications (SPA). Technically a SPA interacts with the web browser by dynamically rewriting the current page with new data from the server, instead of the default method of the browser loading entire new pages. With this new context, the concept and benefits of Page Object Model (specifically in large and complex applications) start to be unclear.
If we strictly follow the POM pattern the SPA representation will consist of a few page classes with a considerable number of elements. In the best scenario we could define an inheritance tree of component classes but still managed by a single page increasing the couple and responsibility of the objects. Changing the focus from Pages to User interactions we can manage a complex SPA maintaining the SOLID principles.
Let’s analyze how Single Page Applications are generally described in a POM world.
In this scenario, the landing or home page contains several sections with multiple elements and interactions. Typically these sections have small flows and views increasing the number of elements that we need to maintain per each page.
Our first try will be to develop a page class where we define all of our elements. Eventually, this class will contain hundreds of lines of code increasing the chance to duplicate selectors and methods due to the lack of readability and low cohesion of the code. We can still split this page in a more manageable component like Martin Fowler says: Despite the term “page” object, these objects shouldn’t usually be built for each page, but rather for the significant elements on a page[8]. But before continuing analyzing better ways to reduce the complexity of Page Objects let’s ask ourselves what we are trying to model? One of the biggest problems when we are building our automation framework using the POM is that sometimes we are focused on describing every action that we can do on a page rather than modeling what users can do and how they are doing it.
As an example we can design one of the multiple tests of this particular type of applications answering the following question:
Who? (Rol) : James as IT professional
Why? (Goals): Scenario: known about career opportunities
What? (Tasks): When I search for opportunities for Mobile development career path
@When(“When I search for opportunities for Mobile development career path”)
public void searchForCareerPath() {
theITProfessional.attempsTo(
SearchCareers.forPathWith(MOBILE_DEVELOPMENT);
);
}
How? (Actions):
Enter.the(searchCareerPath).into(careerPathScreen.searchPath);
Click.onThe(careerPathScreen.searchButton);
Therefore based on the first SOLID principle (S: Single Responsibility) in terms of how many functions the objects handle, the resulting architecture will describe smaller classes instead of few large ones like the following:
| — questions
| | — CareerDetails.java
| | — CareerFilter.java
| | — DisplayedCareer.java
| | — CareerAvailability.java
| | — TheCareerStatus.java
| | — TheCareers.java
|
| — tasks
| | — SearchCareers.java
| | — SeeCareerDetails.java
| | — ClearCareerFilter.java
| | — FilterCareer.java
| | — ApplyForJob.java
|
| — userInterface
| | — ApplicationHomePage.java
| | — Careers.java
| | — CareersDetails.java
| | — ApplyJob.java
Now if we want to add new functionality we need to just create a new class avoiding modifying existing classes and satisfying the second SOLID principle (O: Open Close) describing that one class should be open for extensions but close for modifications.
We can mention that the screenplay pattern is supported by the most commonly used programming languages like Java and javascript[9]. It has native integration with BDD frameworks like JBehave and Cucumber and also includes Selenium and RestAssured as automation frameworks for Web and API respectively.
Should I start refactoring all my code and move to a Screenplay pattern?
The first answer will be NOT. The real benefits of implementing a new design pattern will depend on a number of factors such as application architecture type, team skills, how stable your development process is among others.
My recommendation is to start a new project aside and test how well you feel with the layers organization and coding efficiency, readability, and maintainability as well. Furthermore test different scenarios from simple to more complex in order to foresee possible blockers or issues along the road.
The examples provided here are just an initial guide and help to show the main concepts but implementation can differ and some mixes between patterns can be found. Try to adapt your framework to your needs based on your knowledge and include more reading around the concepts and successful experiences in the market.
Conclusively as a personal thought, Page Object Model is very useful for teams that are learning to implement automation frameworks but as we move through more complex scenarios where multiple teams are involved and automation code increases exponentially, this approach could lead to unclear results if it is not considered as production code. Screenplay patterns allow us to develop more safety and manageable from the start, allowing maintainable and scalable testing frameworks implementations. On the other hand, it is required a good understanding of layers abstraction and programming skills so mature teams can fully benefit from the implementation. A good place to start is at John Ferguson Smart personal web page[10] where you can find documentation, webinar, and online events.
References:
[1]https://blog.aspiresys.com/testing/design-patterns-in-test-automation-world/
[2]Application Under Test
[3]https://www.selenium.dev/documentation/en/guidelines_and_recommendations/page_object_models/
[4]Page Object Model
[5] https://www.infoq.com/articles/Beyond-Page-Objects-Test-Automation-Serenity-Screenplay/
[6] https://serenity-bdd.github.io/theserenitybook/latest/serenity-screenplay.html
[7]SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable
[8] https://martinfowler.com/bliki/PageObject.html
[9]serenity-js.org
