How Important Is the GIVEN-WHEN-THEN pattern in BDD?

How important is it to write BDD tests in a simple GIVEN-WHEN-THEN pattern? Is it bad to write them like: GIVEN-GIVEN-THEN-AND-WHEN-THEN ?

I just started a new position managing testing in a dev shop where testers/devs are using BDD (Specflow) as an abstraction to Selenium and RestSharp tests. This is newish for me. I’ve been reading through their existing library and the gherkin is all over the place, to my eye. I was kind of hoping the tests would be simpler like:

GIVEN the user added these 6 items to their cart
WHEN the user clicks “Show Cart”
THEN the cart displays with all six items

but I’m seeing crazy deviations like:
GIVEN the user added these 6 items to their cart
THEN they add 2 more items
AND they click “Show Cart”
THEN the cart displays with all 8 items
WHEN they click “Back”
THEN they see the product page again
AND they see the “Show Cart” button again

It’s as if the keywords are randomly assigned. Okay, maybe it’s not as bad as I’m describing. Just seems like different authors are structuring GIVEN-WHEN-THEN-AND keywords completely differently.


How important is it to write BDD tests

Not at all. :upside_down_face:
My general take on BDD:

tl;dr I would not use BDD in code, just for specification and acceptance criteria

in a simple GIVEN-WHEN-THEN pattern?

To me it looks like they kinda “misuse” BDD for normal test cases.
But maybe that is a useful way to do it?
Do you think one of both ways is useful at all?

1 Like

Hi Eric

How you write them is very important as they are meant to be easy to read, especially by someone non-technical.
I ran an internal training session on this last year and made the point that it isnt about the UI navigation, but about the actions.
To make it easier to understand, I grouped them as Context, Event, Outcome, where any of the 3 can be multi steps. But, you only have one Given, one When and one Then:

Scenario name – must be meaningful and unique
'Given’ - this is the precondition(s), state or parameters needed. This sets the Context.
'When’ – this is the behaviour or Event we are testing
'Then’ – this is the expected Outcome from the preconditions and the behaviour
‘And’ – this can be used after a ‘Given’, ‘When’ or ‘Then’ statement for additional context, events or outcomes.

Given I log into my banking app
And select my savings account
When I transfer £500 to my current account
Then my savings account balance is reduced by £500
And my current account balance is increased by £500.

The first 2 lines are the Context, the When line is the Action, and the last two lines are the Outcome.

There are more complicated workflows but these for us tend to be where we have to have another user who approves or rejects a change, and then the first user has to then do something afterwards. Rather than splitting them up we do have them written as fairly long scenarios (no more than 20 lines though). As an aside, I reviewed one that was written before I joined the company which has over 100 lines, and many When and Then statements. Took me 3 hours to rewrite it into sensible chunks!!

Hope this helps.


These scenarios with many steps is a sign that one is not doing Behavior-Driven Design, because no one would like to use such interfaces, which don’t allow refactoring, since many responsibilities are entangled in many scenarios.

Before trying to jump on the code, I would look for a deeper problem root cause: How people are coding, if they are driving it using the behavioural descriptions.

1 Like

Thanks @sjwatsonuk ! Very helpful explanation.

1 Like

What I want to add, is that there is a mixture of BDD and unit tests. BDD should not have any detailed information about the implementation like the name of the buttons and screens. According to me the Gherkin scripts were built from the bottom up instead of top down.

A rewrite of your example would lead to:

GIVEN the user has 6 items in the order
WHEN the user adds 2 items to the order
THEN the order contains 8 items.

A more advanced rewrite of your example is:

GIVEN the user has items in the order
WHEN the user adds items
THEN the order contains items.

| start | added | total |
| 0 | 6 | 6 |
| 6 | 2 | 8 |


It also looks like there are 2 tests here. The 1st test is covering that additional items are added to the cart correctly and @han_toan_lim response to that part is excellent btw. The 2nd test starts with the ‘WHEN they click “Back”’, and uses the previous test as context. I would look at splitting that out into its own test with its own context, and repeat what @sjwatsonuk mentioned about avoiding UI navigation terms and making it about the actions, or intent.

1 Like