Cart
0
£0.00
Gherkin Scripting Language
Gherkin language is used to document requirements and define test scenarios.
It is designed to be non-technical and human readable, and collectively describes use case story Feature Scenarios relating to software systems.
Gherkin's natural language syntax is designed to provide simple documentation of the code under test and also provides a basis for automated testing.
Each requirement or user storey can be broken down into one or many Features, written in Gherkin script, and stored in text files with the .Feature extension. The feature file may contain descriptions of the feature, descriptions of Scenarios, Given / When / Then steps, and optionally Scenario Example data.
BDD and Agile
The purpose behind Gherkin's syntax is to promote behaviour-driven development BDD practices across the entire Agile team, including business analysts, developers, QA managers and testers. It seeks to enforce firm, unambiguous requirements starting in the initial phases of requirements discovery and definition by business management in all stages of the development life cycle.
Writing good Gherkin
Behaviour-driven development (BDD) practices can help your teams build better software by making them carefully specify the product's behaviours using plain-language examples. And whether you're seeking better collaboration through "three amigos" meetings or wanting to automate better using a test framework, one language rests at the centre of the BDD movement: Gherkin.
Andy Knight, Lead Software Engineer at Precision Lender has 4 Golden Rules for Good Gherkin:
1. Gherkin's Golden Rule:
Gherkin's Golden Rule is simple: Treat other readers as you would want to be treated. More specifically, write feature files so that everyone can intuitively understand them. Good Gherkin should improve team collaboration by clarifying behaviours you want to develop. When Gherkin is tough for others to read, teams can't develop good behaviours. Here's an example:
Scenario: Add shoes to the shopping cart
Given the shoe store home page is displayed
When the shopper searches for "red pumps"
And the shopper adds the first result to the cart
Then the cart has one pair of "red pumps"
This scenario has declarative, descriptive steps. The steps strictly follow a given-when-then order that clearly shows the setup, the interaction, and the verification of the desired behaviour. The scenario uses "red pumps" as a concrete example to help the reader better understand the scenario. The scenario is concise, yet unambiguous.
2. The cardinal rule of BDD
The cardinal rule of BDD is a one-to-one rule: One scenario should cover exactly one single, independent behaviour. Focusing on one behaviour at a time has several benefits:
- Collaboration: More focus and less confusion
- Automation: Each test failure points to a unique problem
- Efficiency: Less complex work makes for faster cycle times
- Traceability: 1 behaviour → 1 example → 1 scenario → 1 test → 1 result
- Accountability: Teams cannot hide or avoid behaviours
Whenever a scenario has more than one when-then pair, it inherently covers more than one behaviour. Thankfully, splitting scenarios is easy:
Scenario: Simple Web search
Given the shoe store home page is displayed
When the search phrase "red pumps" is entered
Then results for "red pumps" are shown
Scenario: Simple Web image search
Given shoe store search results for "red pumps" are displayed
When the user searches for images from the results page
Then image results for "red pumps" are shown
You can capture the stopping point for the first scenario as a new given step for the second scenario. In this way, the second scenario focuses only on its unique behaviour.
3. The unique example rule
Sometimes, less is more, so don't include unnecessary examples. Focus instead on unique equivalence classes. Testing "all the things" might sound tempting, but that wastes precious time. Instead, test the most important things, and avoid testing duplicate things. Consider the following scenario:
Scenario Outline: Simple product search
Given the shoe store home page is displayed
When the search phrase "<phrase>" is entered
Then results for "<phrase>" are shown
Examples: Shoes
| phrase |
| red pumps |
| sneakers |
| sandals |
| flip flops |
Scenario outlines run the scenario, one for each row in the examples table, so this scenario outline would run seven times. If a typical web UI test takes one minute, then each run will add a lot of time to the whole test suite. All of these examples just cover different types of shoes. Arguably, "shoes" could be an equivalence class, so testing different types of shoes may not be worthwhile. Always carefully consider the examples chosen.
4. The good grammar rule
Language matters, so write as though your high school English teacher will be grading your Gherkin. Behaviour scenarios are meant to be readable and expressive. Steps are meant to be reusable. Poor grammar, misspellings, and inconsistent phrasing can ruin the benefits of behaviour specification. Scenarios can become confusing, and team members could use steps out of context.
One of the biggest language problems with Gherkin is an inconsistent point of view. You can write steps using first-person perspective ("I, me, my") or third-person perspective ("the user ..."). While I strongly favour third-person perspective for Gherkin steps, it is more important for a solution to use one or the other exclusively. Look at what happens when steps mix the point of view:
Scenario: Simple product search
Given I am at the shoe store page
When the user searches for "red pumps"
Then I see web page links for "red pumps"
This scenario is understandable, but looks sloppy. The meaning could also be ambiguous: Am "I" "the user," or is there a second user? Use one point of view for consistency.
Another problem frequently seen involves tense: past, present, and future. Each type of step should follow consistent rules within a solution. I recommend the following:
- Given steps should use past or present-perfect tense, because they represent an initial state that must already be established.
- When steps should use present tense, because they represent actions actively performed as part of the behaviour.
- Then steps should use present or future tense, because they represent what should happen after the behaviour actions.
Practice makes perfect
The rules shared above (thanks Andy) should be your guiding principles for good Gherkin.
Want to learn more about those other rules about Gherkin and BDD? Read Andy's in-depth tutorial.
Agile Guru John Ferguson Smart states....
- Respect the Given..When..Then order
- Write the Given in the past tense ("Tara has completed "), or make it state a fact about the system ("Tara is a Standard Frequent Flyer")
- Write the When in the present
- Write the Then in the future tense, or use the word "should"
The Given sets the stage - it describes the state of the system, or any relevant user actions, before the test starts. The When is the action we are actually interested in. And the Then describes the outcomes we expect.It's a simple structure, and if you follow it strictly, it will go a long way in making your scenarios cleaner and more maintainable.
John poses a Question?
Thanks to John Ferguson Smart for this great example of Gherkin https://johnfergusonsmart.com/
John says "One of the most important rules when writing scenarios is to prefer declarative business rules over imperative test-script style sequences of steps.
I see a lot of teams writing scenarios like the first one.. It is essentially a test script, written in Gherkin.That style is bad Gherkin; you should avoid it. It leads to test suites that are hard to read, hard to maintain, and that fail to do what Gherkin was designed to do: act as a way of expressing requirements in an executable form that the whole team can understand and collaborate on.
The second scenario is similar to the first in many ways. But it reads totally differently. It focuses on capturing the business rules and intent, and not so much on how the user interacts with the application (plenty of time for that in the step definitions).
And more importantly, it's written in business-speak, not tester-speak.
So if you have scenarios like the first one, take some time to refactor them into a cleaner declarative style.
You can thank me later.
Read more on this topic in the Agile Test Automation Playbook - you can grab it here: https://bit.ly/35zlCN8 "