Screenplay Pattern for Test automation: Actions - What an user can do

🎬 Screenplay Pattern - Part 2: Actions
In the Screenplay pattern, once you've defined your actor, the next question is:
What can this actor do?

That's where Actions come in.

🛠️ What are Actions?
Actions are the building blocks of your test.
They define how an actor interacts with the system — but in a reusable and readable way.

Instead of spreading low-level commands all over your tests, you create named tasks that express intention, like:

 bankCustomer.makeAction('enterLoginCredentials', { email: validUser.email, password: validUser.password, }); 

It tells you exactly what’s happening — not how it’s implemented.

How the actions works:

• I use an class for each feature of our system:

export class LoginActions { enterLoginCredentials(input: { email?: string; password?: string }) { loginPage.waitForPageToLoad(); if (input.email) { cy.get(loginPage.getEmailInputSelector()) .filter(':visible') .should('be.enabled') .clear() .type(input.email, { delay: 50 }); } if (input.password) { cy.get(loginPage.getPasswordInputSelector()) .filter(':visible') .should('be.enabled') .clear() .type(input.password, { delay: 50 }); } } } 

The UI selectors are stored in a separate file. By keeping selectors in their own file, they can be reused across different actions.

After this, the actors who can perform this actions, only need:

export default class BankCustomer extends BaseActor { constructor() { const loginActions = new LoginActions(); super(loginActions); } } 

So when you read a test and see an action, it tells you what is being done — not how it's done. If you want to check the implementation, just search for the action name or look it up in the documentation. (Screenplay makes documenting tests easier — more on that later!)

✅ Why use Actions?
Readable: Your test reads like a user story.

Reusable: One action can be used across many scenarios.

Maintainable: If the UI changes, you update the action, not every test.

In short:
Actions help you write tests that describe behavior, not code.
They're a key piece in making automation feel like a conversation between the user and the system.

Next post: ❓Questions – how do we verify what happened?