externalabstractTask
Hierarchy
Index
Constructors
Methods
Constructors
externalconstructor
Parameters
externaldescription: Answerable<string>
externallocation: FileSystemLocation = ...
Returns Task
Methods
staticexternalwhere
A factory method that makes defining custom tasks more convenient.
Parameters
externaldescription: Answerable<string>
A description to be used when reporting this task
externalrest...activities: Activity[]
A sequence of lower-level activities that constitute this task
Returns Task
externalinstantiationLocation
Returns the location where this
Activity
was instantiated.Returns FileSystemLocation
externalabstractperformAs
Parameters
externalactor: PerformsActivities
Learn more
Returns Promise<void>
externaldescribedBy
Resolves the description of this object in the context of the provided
actor
.Parameters
externalactor: AnswersQuestions & UsesAbilities & { name: string }
Returns Promise<string>
externaltoString
Returns a human-readable description of this object.
Returns string
Tasks model sequences of activities and help you capture meaningful steps of an actor workflow in your domain.
Typically, tasks correspond to higher-level, business domain-specific activities like to
BookAPlaneTicket
,PlaceATrade
,TransferFunds
, and so on. However, higher-level tasks can and should be composed of lower-level tasks. For example, a task toSignUp
could be composed of tasks toProvideUsername
andProvidePassword
.The lowest-level tasks in your abstraction hierarchy should be composed of interactions. For example, a low-level task to
ProvideUsername
could be composed of an interaction to enter the value into a form field and press theKey.Enter
.Tasks are the core building block of the Screenplay Pattern, along with actors, abilities, interactions, and questions.
Learn more about:
Defining a task
Defining a not implemented task
Note that calling
Task.where
method without providing the sequence of activities produces a Task that's marked as "pending" in the test report.This feature is useful when you want to quickly write down a task that will be needed in the scenario, but you're not yet sure what activities it will involve.
Composing activities into tasks
The purpose of tasks is to help you capture domain vocabulary by associating domain meaning with a sequence of activities. From the implementation perspective, tasks help you give a meaningful description to such sequence and provide a way to easily reuse activities across your code base.
Tasks associate domain meaning with a sequence of lower-level activities and provide a mechanism for code reuse.
For example, a task to find a flight connection from London to New York could be modelled as a sequence of the following lower-level activities:
The easiest way to implement such task, and any custom Serenity/JS task for this matter, is to use the
Task.where
method to compose the lower-level activities:Furthermore, if the actor was interacting with a web UI, a task to specify origin city could again be composed of other activities:
origin airport
widgetLondon
Conversely, a task to specify destination city could be composed of:
destination airport
widgetNew York
Conveniently, Serenity/JS modules provide low-level activities that allow actors to interact with the various interfaces of the system under test. For example, Serenity/JS Web module ships with activities such as
Click
orEnter
, which we can incorporate into our task definitions just like any other activities:As you can already see, tasks to specify origin city and specify destination city are almost identical, save for the name of the widget and the text value the actor is supposed to enter. Serenity/JS task-based code reuse model means that we can clean up such duplicated implementation by extracting a parameterised task, in this case called
specifyCity
:As you work with Serenity/JS, you'll notice that the ideas of functional decomposition, so thinking of tasks as sequences of lower-level activities, as well as functional composition, so implementing reusable activities and composing them into higher-level tasks, are at the heart of the Screenplay Pattern. You'll also notice that the entire Serenity/JS framework does it best to help your team follow this approach.
What makes the Serenity/JS task-based code reuse model so powerful at scale is the observation that:
What this means in practice is that by investing your time in properly designing relatively few reusable tasks to test your system, you give your team a significant productivity boost and leverage when producing high-level test scenarios.
On top of that, this design approach results not only in simpler test scenarios that reduce the cognitive load on the reader as they require them to process the scenario only one level of abstraction at the time. It also allows for the test to take shortcuts in well-defined points of the workflow - use a REST API request to create a test user account instead of going through the registration form.