Cucumber ordering of Given, When, Then (Given, When, Then, When, Then)

Question

As an End-to-end Automation Tester I have always assumed that Given, When, Then statements (incorporated in the Gherkin Language when using Cucumber) should only ever appear in the order of 1. Given, 2. When, 3. Then.

i.e. A test should not follow, for example, Given, When, Then, When, Then. And instead should follow Given, When, Then only.

The reason for this assumption was along the lines of a single test only testing one area of the application.

However, I noticed on some gherkin examples on the web, that they use the following ordering sometimes: Given, When, Then, When, Then.

Does anyone know if this moving back to Whens after writing a Then is acceptable best practice? I appreciate the test will still work, just wondering if this is good or bad practice.

Answer 1

Syntactically Interchangeable; Linguistically Different

The Gherkin syntax currently includes six keywords for describing feature steps:

1. Given
2. When
3. Then
4. And
5. But
6. *

The keywords are there for human consumption and the ease of conveying business logic. However, the Gherkin language itself treats the keywords as interchangeable symbols, so you could just as grammatically (from a Gherkin point of view) write tortured English like:

But for a dollar held
Then another dollar more
Given ownership of two dollars am I.

This is perfectly valid Gherkin, but a terrible representation of counting money. So, if all the words are interchangeable, why have so many of them? The wiki is quite clear that they provide a set of conventions to facilitate communication in a more natural style, and the wiki even gives a few examples of how the words are meant to be differentiated. The wiki also specifically says:

Cucumber doesn’t technically distinguish between these...[kinds] of steps. However, we strongly recommend that you do! These words have been carefully selected for their purpose, and you should know what the purpose is to get into the BDD mindset.

In other words, use the Gherkin terms to communicate in (relatively) natural language about your feature, and bury the arcana in step definitions. Use whatever keyword fits most naturally in the linguistic flow, and don't sweat a well-written scenario that doesn't rigidly adhere to a convention that may not apply in all cases.

Answer 2

Although scenarios can be written in that way, it is not best practice. I for one, have made that mistake and it can cause problems in reports and maintenance.

One reason would be that When declares an action and Then verifies the result of that action. Having When - Then twice goes against the individual behavior of a scenario.

Can also get confusing for someone who reads the scenario :)

Here's a little post regarding this

Answer 3

There is alot of really bad Gherkin on the web. Also there is a range of opinions about what good Gherkin is.

My opinion is that When Then When Then is an anti-pattern. Its likely that one of the following is required

1. You need a better Given to incorporate the first When Then

or

2. You need to split the scenario in two.

In general most When's in scenario's become Given's in later scenario's, as you build on existing behaviour to define and create new behaviour.