Gherkin Given/When/Then
For describing the detailed steps of the Feature Scenarios.
Given / When / Then:
Given steps are used to describe the initial context of the system, the scene of the scenario. Typically something that has happened in the past, some configuration to get the system into a known state. This can be a user is logged in, or some navigation to be on the required page, or finding a user that has enough money in their account to complete the transaction.
When steps are used to describe events or actions that will fulfil the requirement of the feature. So, When the customer inserts their card into the ATM and withdraws £10 cash.
Then steps will check the results of the actions are as Expected, so £10 cash is dispensed from the ATM and Then the account balance is reduced accordingly.
Industry Gherkin Definitions
Angie Jones, Senior Developer Advocate tells us Features should be clear & concise Writing Good Gherkin
Good Concise Gherkin
Yes, a lot of detail is missing here. But that's ok. You may ask how will we know how to implement this? We leave that to whomever is writing the automation code. Just as we trust the developers to be able to develop the feature without the implementation details.
Verses Too Much Detail
This example does provide a lot more detail but there are some cons to this approach. In addition to reducing the re-usability of the steps, these steps contain a ton of implementation detail and explicitly dictate how the automation should be written. One reason that the three amigos come up with scenarios that focus on behaviour and not implementation, is because how you make this happen isn't really relevant, and by adding all of this detail, you're losing the intent of the scenario's behaviour. Thanks to Angie Jones for the above.
Reusable Scenarios : Step Definition Glue
.
.
.
.
Break down your concise Given / When / Then steps into smaller 'Reusable' Step Definition chunks that can be stored as Scenario .Feature files, containing all the detail to be included at run time.
GherkinUFT : Mix and Match
In the example below, we have a mix of both Concise & Detail styles. There are 4 steps that describe high level actions (Navigation, Selection, Verification and Sign-Out) and 2 steps that are detailed step definitions. The result is an easy to read .Feature that is not too long, and flexible using Scenario <Example_Data>. This feature is held in a text .Feature file, being edited in Notepad++
Another example .Feature is held in an Excel datasheet, again, with a mix of both Concise & Detail styles. There are 4 steps that describe high level actions (Start, Login, Validate-Offer and Sign-Out) and 5 steps that are detailed step descriptions.