-
Notifications
You must be signed in to change notification settings - Fork 0
MakeupOfAScreenplayTest
Screenplay tests are about Actors performing Tasks which describe their interactions with the application. 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 which the actor provides.
Include a testing architecture diagram here
The type of class which test writers are likely to spend most of their time writing are Tasks.
All Screenplay tests begin with an Actor. The actor represents something external to the software and is the trigger which causes the application to perform some work. An obvious example is that of a human user interacting with the application. Actors could also correspond to a more abstract concept, such as an external job scheduler.
Actors have 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.
Where many different test scenarios need an actor with the same conceptual role you are encouraged to reuse the same name for each, as if it were the same actor. The effect is that your test suite will accumulate up a collection of well-known actors. Screenplay formalises this via Personas - classes which describe a 'type of actor' along with their name & 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, an object will be required which provides an API by which a web browser is controlled.
Abilities are 'granted' to an actor, creating an association. Actions & Questions retrieve abilities as they are required from the actors performing the action/asking the 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. Rather the differences between these three are conceptual.
Let's examine these three types from high-level to low-level.
Tasks are the highest-level performable operation and the only type of performable which should be composed solely of other performables. Tasks may describe complex interactions between the actor and the software under test.
The simplest possible 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.
A task could be as simple as Log in with a username and password or it could be as complex as Order any items on my wish-list which are discounted
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.