Testla — Screenplay for Playwright
Most test automation projects use the Page Object Model as the de facto pattern for automating web UI interactions. Most of the time, we all agree on benefits and how we should define them. The simple structure makes it possible to avoid early maintenance problems, which is satisfying in many situations.
Sometimes we leave out other factors that might challenge this approach. The main reason to consider an alternative is that the Page Object Model forces the quality engineer to think in terms of “pages” rather than the actual behavior of the application. The primary interest of our tests should be the interaction of the application, the secondary is the implementation.
Why you should use design patterns in your automation
Test automation is an independent software development project. Therefore, the test patterns are very similar to the design patterns used in software development. The most difficult aspect of test automation development has always been code maintenance. Many test automation projects have gone under or been abandoned because frameworks couldn’t keep up with growing code bases and constantly changing functionality. To keep maintenance costs low, quality engineers should strive to minimize the code they reinvent or create using existing functions for common, generic, or repetitive interactions from scratch.
What is the Screenplay Pattern?
One way to define testing is interactions plus verification. That’s it. Interactions are units of behavior. That means: They are indispensable to testing.
Think about any functional test case you’ve ever written or executed. The test case is a step-by-step procedure in which each step has interactions and checks.
Let’s take a closer look at how interactions happen. First there is an actor who starts interactions. Usually these are the users. They are the ones making the clicks, taking the scrapes, all those kinds of things.
Second, there is the product under test, for example, a web application. It has pages with elements. The web page structure is modeled so that locators are used to access page elements from the dom.
Third, there are the interactions for web applications. These can be simple clicks and keystrokes or more complex interactions such as logging into the application. Each interaction performs the same type of operation on the target page or element assigned to it.
Finally, there are objects that allow actors to perform certain types of interactions. For example, browser interactions require a tool like Playwright to perform clicks and scrapes. Let’s call this abilities.
Actors, abilities, and interactions are several types of concerns each. We could summarize the relationship in one line.
Actors use abilities to perform interactions. This is the center of the Screenplay Pattern.
In the Page Object Model, page objects become messy because all concerns are combined. The Screenplay Pattern separates concerns from maximal reusability and scalability. It is a design pattern to help write better interactions for better automation.
This view will change the way we look at the application and how we want to model it. It takes away the idea that an application is a bunch of pages interacting with each other. Instead, we are provided with an actor that plays a specific role. In this role, the actor will try to achieve a goal by performing certain tasks.
Each of these tasks can be achieved by a combination of interactions with the system. Looking at the application from the actor perspective is often used when working in a Behavior Driven Development (BDD) environment. This view focuses on the user and their capabilities rather than the application itself. This way of modeling the application is called Screenplay Pattern.
Why use @testla/screenplay-playwright?
@testla/screenplay-playwright is a JavaScript implementation of the Screenplay Pattern. It is a library that helps you write better interactions for better automation! Let’s dive into the Screenplay Pattern for test automation with @testla/screenplay-playwright provides rich, and reliable interactions out of the box. You don’t have to implement your own pattern. You don’t need to rely on raw Playwright calls.
The interactions are also composable. You can create new interactions that call other interactions. This transforms test automation from a series of clicks and scrapes to meaningful tests or procedures. Here’s what the full test looks like, and let’s break it down further.
The actor can browse the web. We defined that in a fixture. You can read more about fixtures here.
Actors execute tasks to achieve their goal. James can perform certain tasks. They use their ability to interact with the system to perform the task(s).
Interactions or actions are classes which encapsulate interactions between the actor and the system. We don’t think in terms of pages, but in terms of behavior of how the user interacts with the system.
Conclusion
The Screenplay Pattern isn’t exactly new. It’s been around for several years. The examples given here are only a first guide and show the most important concepts. Try to adjust your test automation to your needs based on your knowledge and read more about the concepts and successful experiences on the market.
In conclusion, the Page Object Model is extremely useful for teams learning to implement test automation. However, when we go through more complex scenarios involving multiple teams and the automation code increases exponentially, this approach could lead to ambiguous results if not considered as production code.
Screenplay Pattern allows us to develop more safety and manageable tests from the start, allowing maintainable and scalable test automation implementations. On the other hand, a good understanding of layers, abstraction, and programming skills is needed so mature teams can fully benefit from the implementation.
