MakeupOfAScreenplayTest
In a Screenplay test, one or more Actors perform Tasks which describe their interactions with the software under test. High-level tasks are created by composing lower-level ones. The most granular interactions are named Actions ("do something") & Questions ("read/get something"). Actions & questions interact with the application under test by way of Abilities, provided by the actor.
Of the kinds of objects mentioned above, developers writing Screenplay test logic are most likely to be concerned with Tasks.
All Screenplay tests begin with at least one Actor. The actor represents/simulates something or someone using the software under test. The most common kind of actor represents a human user interacting with the application. An actor could also be used to represent/simulate an external application which interacts with the software, like a cron or Windows Task Scheduler job.
Actors have Abilities and it is those abilities which enable Actions and Questions to interact with the software under test. During the course of a test scenario, an actor is identified by a name. Two actors in the same scenario may not share the same name.
It's common for different test scenarios to use actors with the same conceptual role and abilities. In this case you are encouraged to reuse the same name for those actors across different scenarios. This does not mean that those scenarios are reusing the same actor object. Instead it means that those actor names can become recognisable across the dev team, associated with their role.
Screenplay formalises this practice via Personas - classes which describe a 'type of actor' with a name & some abilities.
The lowest-level interactions with the application are defined by Actions & Questions. Abilities provide the dependencies for those interactions to do their work. For example, in end-to-end acceptance tests for a web application, a dependency object is needed to provide an API by which a web browser is controlled (for example a WebDriver).
Abilities are 'granted' to an actor, creating an association. Actions & Questions retrieve the abilities they need from the actor performing the action/question.
Abilities' sole purpose is to provide (usually) a single dependency object which might otherwise be complex to create. Abilities should not contain any logic which relates to how that dependency is used; that is the role of actions and questions.
Collectively, Actions, Questions & Tasks may be referred to as 'performables'. They all describe something that an actor can either do or can see/read/get. The architecture and design of these the types of class are very similar; their differences are mainly conceptual in nature.
Tasks are the highest-level performable and should be composed solely of other performables. Tasks may describe complex interactions between the actor and the software under test.
The simplest tasks are compositions of Actions and/or Questions which represent the actor performing a logical operation upon the software under test. Tasks may return a value (behaving like a question does) or they might simply do something (behaving like an action).
The true power of tasks is that they may themselves be composed from other tasks. Thus high-level tasks may be built up from reusable logic in lower-level ones.
As a developer writing tests, it's expected that most of your development effort for tests will be spent writing tasks.
Where tasks represent high-level logical interactions, Actions represent single operations which cannot be meaningfully split up into smaller steps.
Actions should interact directly with an actor's relevant Ability in order to do their work. Actions do not return any result, they either succeed or they raise an exception.
When testing a web application, a mouse-click is a good example of an action.
Like actions, questions also represent single, granular interactions with the application. Unlike actions, questions do not 'do something' to the software under test, they read/get some information in some manner. Thus, questions always return a value of some kind.
In web application testing, getting the text of an HTML element is the sort of thing you would expect from a question.