Retrieves actor’s Ability of
abilityType, or one that extends
Please note that this method performs an instanceof check against abilities given to this actor via Actor.whoCan.
Please also note that Actor.whoCan performs the same check when abilities are assigned to the actor to ensure the actor has at most one instance of a given ability type.
- T: Ability<T>
Instructs the actor to attempt to perform a number of activities, so either Tasks or Interactions), one by one.
The answer to the Answerable
optionalname: string | Name
Instructs the actor to invoke Discardable.discard method on any Discardable Ability it’s been configured with.
Returns a human-readable, string representation of this actor and their abilities.
PRO TIP: To get the name of the actor, use Actor.name
Actors represent people and external systems interacting with the system under test. Their role is to perform activities that demonstrate how to accomplish a given goal.
Actors are the core building block of the Screenplay Pattern, along with Abilities, Interactions, Tasks, and Questions. Actors are also the first thing you see in a typical Serenity/JS test scenario.
Learn more about:
Representing people and systems as actors
To use a Serenity/JS Actor, all you need is to say their name:
Serenity/JS actors perform within the scope of a test scenario, so the first time you invoke actorCalled, Serenity/JS instantiates a new actor from the default Cast of actors (or any custom cast you might have configured). Any subsequent invocations of this function within the scope of the same test scenario retrieve the already instantiated actor, identified by their name.
Serenity/JS scenarios can involve as many or as few actors as you need to model the given business workflow. For example, you might want to use multiple actors in test scenarios that model how different people perform different parts of a larger business process, such as reviewing and approving a loan application. It is also quite common to introduce supporting actors to perform administrative tasks, like setting up test data and environment, or audit tasks, like checking the logs or messages emitted to a message queue by the system under test.
Actor names can be much more than just simple identifiers like
Bob. While you can give your actors any names you like, a good convention to follow is to give them names indicating the personae they represent or the role they play in the system.
Just like the characters in Stan Lee graphic novels, actors in Serenity/JS test scenarios are often given alliterate names as a mnemonic device. Names like “Adam the Admin”, “Edna the Editor”, “Trevor the Traveller”, are far more memorable than a generic “UI user” or “API user”. They’re also much easier for people to associate with the context, constraints, and affordances of the given actor.