When I describe my morning it invariably sounds boringly like the following:
“This morning I left the house, locking it with my key, and then I took a train, as I have a ticket, to London Waterloo East before taking the Tube, because I have a ticket, to the windy monoliths of Canary Wharf."
Ok, so it’s not the most riveting of stories! But it does effectively explain my experience as I journey in towards London and some of our clients.
If I was to describe the above interaction in terms of web acceptance testing, it would look like the following:
“Leave and Lock House; Interact to Catch Train; Interact to Catch Tube; Assert that I’m in Canary Wharf”.
That’s pretty ugly, and look at the information that has been lost in translation! Specifically I’ve lost the person involved, me, the abilities that I have, and the tasks I accomplish.
“This morning Russ (the Actor) left the house, locking it (Task) with my key (Ability), and then I took a train (Task), as I have a ticket (another Ability), to London Waterloo East before taking the Tube (Task), because I have a ticket (another Ability), to the windy monoliths of Canary Wharf (Consequence!)."
I want to describe a journey in my tests, a flow that the participants are involved in, not just a set of interactions.
And now as of Serenity BDD 1.1.5 I get this capability.
The Journey Model
Serenity BDD has now incorporated an early version of a new conceptual model, the Journey Model for describing the behaviour, or more accurately the journey, that needs to be supported by the software system under test.
I originally encountered the Journey Model in this post by Andy Palmer.
For those that have grabbed the Serenity Core code, implementation is in the serenity-journey package.
In the past when you are creating tests that assert the behaviour of a given web-based system you would capture the important interactions of the test through Steps. A typical test would look like the following from the Serenity BDD samples:
@Steps
public GoogleSearchSteps steps;
@Test
public void searching_for_cats_should_find_the_wikipedia_entry() {
steps.open_home_page();
steps.searchFor("cats");
steps.resultListShouldContain("Cat - Wikipedia, the free encyclopedia");
}
Throughout the test there is a set of Steps, scoped for the test, that encapsulate a number of interactions with Page Objects to lead to a point where some useful assertions could be applied.
Knowing the What, Losing the WhoThe challenge with this Page Object interaction model is that a lot of detail is lost.
We know what happens, but not Who does it, or even what they are capable of!
When stakeholders are describing their stories for how the software should work, who is often as important as what.
What is needed is a new model that describes who does what in the form of a larger narrative.
Enter, stage left, the Journey Model.
Who and Their Journey
The Journey Model focusses on describing the flow using the driving concept of the people, and or systems, involved.
“This morning I left the house, locking it with my key, and then I took a train, as I have a ticket, to London Waterloo East before taking the Tube, because I have a ticket, to the windy monoliths of Canary Wharf."
Ok, so it’s not the most riveting of stories! But it does effectively explain my experience as I journey in towards London and some of our clients.
If I was to describe the above interaction in terms of web acceptance testing, it would look like the following:
“Leave and Lock House; Interact to Catch Train; Interact to Catch Tube; Assert that I’m in Canary Wharf”.
That’s pretty ugly, and look at the information that has been lost in translation! Specifically I’ve lost the person involved, me, the abilities that I have, and the tasks I accomplish.
“This morning Russ (the Actor) left the house, locking it (Task) with my key (Ability), and then I took a train (Task), as I have a ticket (another Ability), to London Waterloo East before taking the Tube (Task), because I have a ticket (another Ability), to the windy monoliths of Canary Wharf (Consequence!)."
I want to describe a journey in my tests, a flow that the participants are involved in, not just a set of interactions.
And now as of Serenity BDD 1.1.5 I get this capability.
The Journey Model
Serenity BDD has now incorporated an early version of a new conceptual model, the Journey Model for describing the behaviour, or more accurately the journey, that needs to be supported by the software system under test.
I originally encountered the Journey Model in this post by Andy Palmer.
For those that have grabbed the Serenity Core code, implementation is in the serenity-journey package.
In the past when you are creating tests that assert the behaviour of a given web-based system you would capture the important interactions of the test through Steps. A typical test would look like the following from the Serenity BDD samples:
@Steps
public GoogleSearchSteps steps;
@Test
public void searching_for_cats_should_find_the_wikipedia_entry() {
steps.open_home_page();
steps.searchFor("cats");
steps.resultListShouldContain("Cat - Wikipedia, the free encyclopedia");
}
Throughout the test there is a set of Steps, scoped for the test, that encapsulate a number of interactions with Page Objects to lead to a point where some useful assertions could be applied.
Knowing the What, Losing the WhoThe challenge with this Page Object interaction model is that a lot of detail is lost.
We know what happens, but not Who does it, or even what they are capable of!
When stakeholders are describing their stories for how the software should work, who is often as important as what.
What is needed is a new model that describes who does what in the form of a larger narrative.
Enter, stage left, the Journey Model.
Who and Their Journey
The Journey Model focusses on describing the flow using the driving concept of the people, and or systems, involved.
Breaking the model down, here are the important concepts:
Those are the key concepts, time to look at some code.
A Journey in Serenity BDD Code
The sample code below comes from the current sample that is part of the core Serenity BDD source code.
Starting aptly from the outside-in, let’s first take a look at the Journey model being used in the actual Serenity test:
@Test
public void danaCanClickOnButtons() {
Actor dana = new Actor("Dana");
dana.can(BrowseTheWeb.with(driver));
givenThat(dana).has(openedTheApplication);
when(dana).attemptsTo(viewHerProfile);
and(dana).attemptsTo(updateHer.name().to("Dana"));
then(dana).should(seeThat(herProfile.name(), equalTo("Dana")));
}
The first thing to do in a Journey model test is to create the Who, the Actor. In our case the actor is Dana and she is going to be able to do some things.
The next line introduces an Ability to Dana, she can BrowseTheWeb using a particular Serenity managed WebDriver.
Next Dana is asked to do some things, some Tasks. Tasks are captured as special Serenity Steps, special in that they contain only one step in each case.
Finally a number of Consequences, combinations of Questions and Hamcrest Matchers in this case, applied to assert that Dana should be able to do something after those tasks.
Watch this Space
This implementation of the Journey model is incredibly useful but there is plenty more to come.
Keep watching this space for more examples of the Journey model as additional features are added.
One area I’m especially interested in is how the Journey model can be used to more effectively communicate and build confidence in a collection of microservices...
- Actors - The People or Systems that drive the journey’s flow.
- Abilities - Things that enable and actors to actually do something.
- Tasks - Activities that an Actor will Perform.
- Consequence - An expectation set up as a Question and an answering Matcher.
Those are the key concepts, time to look at some code.
A Journey in Serenity BDD Code
The sample code below comes from the current sample that is part of the core Serenity BDD source code.
Starting aptly from the outside-in, let’s first take a look at the Journey model being used in the actual Serenity test:
@Test
public void danaCanClickOnButtons() {
Actor dana = new Actor("Dana");
dana.can(BrowseTheWeb.with(driver));
givenThat(dana).has(openedTheApplication);
when(dana).attemptsTo(viewHerProfile);
and(dana).attemptsTo(updateHer.name().to("Dana"));
then(dana).should(seeThat(herProfile.name(), equalTo("Dana")));
}
The first thing to do in a Journey model test is to create the Who, the Actor. In our case the actor is Dana and she is going to be able to do some things.
The next line introduces an Ability to Dana, she can BrowseTheWeb using a particular Serenity managed WebDriver.
Next Dana is asked to do some things, some Tasks. Tasks are captured as special Serenity Steps, special in that they contain only one step in each case.
Finally a number of Consequences, combinations of Questions and Hamcrest Matchers in this case, applied to assert that Dana should be able to do something after those tasks.
Watch this Space
This implementation of the Journey model is incredibly useful but there is plenty more to come.
Keep watching this space for more examples of the Journey model as additional features are added.
One area I’m especially interested in is how the Journey model can be used to more effectively communicate and build confidence in a collection of microservices...
RSS Feed
