liveBook · Manning

Actor

As explained in BDD in Action, Second Edition

An actor is a person, system, or process that interacts with the system under test and pursues goals through activities and abilities.

A flight-booking system may serve travelers, while call center staff handle requests the website cannot. Identifying only “the user” can hide these different goals and workflows. An actor names a person, external system, or process whose interaction with the system matters. section 4.3.3 section 14.2.2

Actors help answer two related questions:

  • In impact mapping, who can help achieve—or prevent—a business goal? Identify people affected by the outcome, including those for whom a change may be inconvenient, before choosing features. section 4.3 section 4.3.3
  • In a Screenplay test, who performs each activity? An actor pursues a goal through business-level tasks, rather than being defined by a screen or a sequence of clicks. section 12.2 section 12.4

Make a multi-person workflow explicit

A loan application needs a client to apply and bank employees to review and approve or reject it. Giving each participant an actor keeps their activities distinct. For a simpler flight-booking test, a traveler can attempt a BookAFlight task expressed in business terms; its interactions can then be reused within other tasks. section 12.1 section 12.4

In test automation, an actor needs abilities to use an interface, such as browsing the web or calling an API. A Cast prepares actors and makes them available by name across scenario steps. Use a shared configuration when actors need the same abilities; use a custom Cast when personas need distinct details or credentials. section 12.10.1 section 14.2.3

Listing 14.1 Configuring a generic cast of actors to use Playwright
import { BeforeAll, AfterAll } from '@cucumber/cucumber'
import { configure, Cast } from '@serenity-js/core'
import { BrowseTheWebWithPlaywright } from '@serenity-js/playwright'
import * as playwright from 'playwright'
 
let browser: playwright.Browser
 
BeforeAll(async () => {                            #1
 
  browser = await playwright.chromium.launch({     #2
    headless: true,
  })
    
  configure({                                      #3
    actors: Cast.whereEveryoneCan( 
 
      BrowseTheWebWithPlaywright.using(browser),   #4
    ) 
  })
})
 
 
AfterAll(async () => {                             #5
  await browser.close()
})

This configuration gives every actor the same Playwright-backed web-browsing ability before scenarios run. section 14.2.2

How BDD in Action, Second Edition covers it

How deep it goes
Defines actors and shows task performance, abilities, and Cast configuration through worked automation examples.
Examples
Uses flight booking, loan approval, and Playwright-backed actor configuration to distinguish goals, participants, and abilities.
What it assumes
Introduces the actor definition before using Gherkin scenarios and Java or TypeScript test code.
What you can do after
Build it from scratch: identify actors and goals, then configure actors to perform reusable business tasks in tests.
How it connects
Links impact mapping and personas to Screenplay tasks, interactions, abilities, questions, and casts.

Also explained in

Compare how 7 books explain actor →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of BDD in Action, Second Edition. The section links point to the parts of the book it draws on.