Given-When-Then is a style of representing tests - or as its advocates would say - specifying a system's behavior using
SpecificationByExample. It's an approach developed by
Dan North and Chris Matts as part of
Behavior-Driven Development (BDD).
[1] It appears as a structuring approach for many testing frameworks such as Cucumber. You can also look at it as a reformulation of the
Four-Phase Test pattern.
The essential idea is to break down writing a scenario (or test) into three sections:
- The given part describes the state of the world before you begin the behavior you're specifying in this scenario. You can think of it as the pre-conditions to the test.
- The when section is that behavior that you're specifying.
- Finally the then section describes the changes you expect due to the specified behavior.
INTRODUCING BDD
:
https://dannorth.net/introducing-bdd/
As a [X]
I want [Y]
so that [Z]
where Y is some feature, Z is the benefit or value of the feature, and X is the person (or role) who will benefit. Its strength is that it forces you to identify the value of delivering a story when you first define it. When there is no real business value for a story, it often comes down to something like ” . . . I want [some feature] so that [I just do, ok?].” This can make it easier to descope some of the more esoteric requirements.
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.
To illustrate, let’s use the classic example of an ATM machine. One of the story cards might look like this:
+Title: Customer withdraws cash+
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
So how do we know when we have delivered this story? There are several scenarios to consider: the account may be in credit, the account may be overdrawn but within the overdraft limit, the account may be overdrawn beyond the overdraft limit. Of course, there will be other scenarios, such as if the account is in credit but this withdrawal makes it overdrawn, or if the dispenser has insufficient cash.
Using the given-when-then template, the first two scenarios might look like this:
+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Notice the use of “and” to connect multiple givens or multiple outcomes in a natural way.
+Scenario 2: Account is overdrawn past the overdraft limit+
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned
.
means take the integer part of 
and is called a