BDD done easy – The level interactions

There are three levels of scenarios in BDD. In this post I will describe the interactions between the levels to show how the scenarios can be more easily created.

In the last post, we created a scenario at the User Level…

• GIVEN I have an account
• AND I’ve set up automatic payments
• AND I have selected a product
• WHEN I place an order
• THEN the item is delivered to my doorstep
• AND the payment amount is debited from my credit card

…and identified the internal systems that will form the value stream.

We will now use this example to illustrate the relationship between GIVEN-WHEN-THEN scenarios. These are easy to identify when you work backwards. The relationships we will discuss are:

1. The “THEN” at the user level is the same “THEN” at the system level and is the starting point for creating the scenarios at the system level.
2. For every GIVEN, there is a THEN in another preceding scenario in that system. In fact, the GIVEN in one Scenario, IS the THEN in the preceding scenario.
3. For every WHEN as a result of a message from another system, there is a THEN in the other system.
4. System Level interactions with the user need to be reflected in the User Level Scenario.
5. Each “GIVEN”, “WHEN” and  “THEN” at the user view level has to exist in a system at the system level.
6. The start scenario has no context (i.e. No Given).

These rules give clear direction for tooling, especially when combined with the “Business Model” and examples already created prior to the GIVEN-WHEN-THEN scenarios.

I am going to write TODO next to those paths that I am not going to expand in this blog. These paths won’t add any clarity to the point being made and make a handy piece of homework for anyone who would care to follow them through.

We start with rule 1…

The “THEN” at the user level is the same “THEN” at the system level and is the starting point for creating the scenarios at the system level.

The value stream ends with the fulfillment system:

• THEN the item is delivered to my doorstep
• WHEN the driver hands me the package
• GIVEN the driver has the package
• AND the driver has my address (TODO)

For every GIVEN, there is a THEN in another preceding scenario in that system.

Working backwards, each GIVEN becomes a THEN, namely THEN the driver has the package & THEN the driver has my address

• THEN the driver has the package
• WHEN the warehouse worker gives the driver the package
• GIVEN the account system has marked the items as “Paid For”
• AND the item has been packed. (TODO)

Working backwards again, GIVEN the account system has marked the items as “Paid For” and AND the item has been packed.

• THEN the account system has marked the items as “Paid For”
• WHEN the account system notifies the fulfillment system that the item is “Paid For”
• GIVEN the fulfillment system has the order (TODO)

For every WHEN as a result of a message from another system, there is a THEN in the other system.

The WHEN from the accounts system results in a THEN in the accounts system.

• THEN the account system notifies the fulfillment system that the item is “Paid For”
• WHEN the account system receives a confirmation from the external payment service
• GIVEN the account system requested a confirmation from the Bank’s external payment system.

Obviously, we choose not to describe the Bank’s payment system. However we know that this step maps to the AND the payment amount is debited from my credit card in the User Level Scenario.

• THEN the account system requested a confirmation from the Bank’s external payment system.
• WHEN the account system receives an item purchase request from the order system
• GIVEN the user has valid credit card details stored (TODO)

The WHEN from the order system system results in a THEN in the order system.

• THEN the order system publishes an item purchase request
• AND provides an acknowledgement to the mobile app
• AND e:mails a confirmation to the user
• WHEN the mobile app creates an order in the order system

System Level interactions with the user need to be reflected in the User Level Scenario.

The red output indicates something that iteracts with the user that is not on the user level scenario which means that the user level scenario needs updating.

• GIVEN I have an account
• AND I’ve set up automatic payments
• AND I have selected a product
• WHEN I place an order
• THEN I receive an e:mail confirmation
• AND the item is delivered to my doorstep
• AND the payment amount is debited from my credit card

The WHEN from the mobile app system results in a THEN in the mobile app.

• THEN the mobile app creates an order in the order system
• WHEN I place an order
• GIVEN I am logged in
• AND I’ve set up automatic payments (TODO)
  
• AND I have selected a product (TODO)

Each “GIVEN”, “WHEN” and  “THEN” at the user view level has to exist in a system at the system level.

So far every “GIVEN”, “WHEN” and “THEN” has been accounted for except for “GIVEN I have an account”. We know we are not finished.

GIVEN I am logged in results in a THEN

• THEN I am logged in
• WHEN I supply the correct username and password
• GIVEN I have an account

A finally we have accounted for all of the “GIVEN”, “WHEN” and “THEN”s.

We may decide to replace GIVEN I have an account with GIVEN I am logged in in the User Level Scenarios for clarity.

The start scenario has no context (i.e. No Given).

Eventually we get to scenario that requires no context in the system.

GIVEN I have an account results in a THEN

• THEN I have an account
• WHEN I create an account

No context is necessary. The account could be created through an API or a Screen or….

We have now reached the Start scenarios. Time to go back and handle all the TODOs, especially the quality paths that I did not even mention.

Although I said there are three levels, I was lying. There are more. However the rules to describe the relationship between scenario in different levels and different systems/components are universal. ( I think ).

In the next post I will discuss some theoretical implications of this on tooling and managing test suites.

If I did not have the flu I would have created more images to illustrate the points. 🙂

My thanks to Mihai Tudor for co-creating this clarity of understanding.