Good communication can not only improve the understanding of team members and positively influence their collaboration skills but also speed up the process of software development. Practices like Behaviour-Driven development influence the communication between the so-called ‘three amigos’ - business, development and testing.
All that can be achieved by using the Gherkin language - one of the most popular languages for writing behaviour specifications. This article will serve you as a beginner guide to Gherkin. You will find out how to use it in practice and how it will help you improve your organisation.
What is BDD?
Before diving into Gherkin, we need to focus on the basic rules of testing for a bit. One of those rules is Behaviour-Driven Development. BDD grew out of Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) and is a part of Agile software development processes that encourages collaboration among developers, QA and non-technical business participants in a software project.
BDD focuses on identifying the desired behaviour of a given feature from the very beginning. The behaviour here means how a product or feature operates and is defined as a scenario of inputs, actions and outcomes.
A product or feature has countless behaviours and identifying them brings clarity and simplicity. Those behaviour specs are written with realistic examples and serve as both the product’s requirements/acceptance criteria and its test cases after development. BDD aims to improve communication between team members, support clarity and minimise hand-overs. The key points of Behaviour-Driven Development are:
- BDD is a paradigm shift
- BDD focuses on behaviour first
- BDD is specification by example
- BDD is a refinement of the Agile process
BDD also encourages applying the ‘Five Why’s’ principle to each user story to find a clear purpose for them.
What is the Gherkin language?
Gherkin is one of the most popular domain-specific languages for writing use cases for a software system in plain language. It promotes behaviour-driven development and allows developers, managers and business officials involved in the process to clearly understand the requirements of the project and the life-cycle. What is more, Gherkin’s text acts as documentation and skeleton of automated tests.
The official Gherkin language standard is maintained by Cucumber - an open-source software testing tool that supports BDD. Cucumber works with Gherkin syntax structures because they are plain text making them easy to read. Cucumber reads Gherkin tests and validates the code checking if it performs as it should. Then, it creates a report showing if each step and scenario was successful.
How are Gherkin test scenarios useful?
Now you might be wondering why it is worth directing your attention towards Gherkin. How will it improve your communication and in return, the development process? Let’s discuss.
Benefits of BDD
You should consider choosing Behaviour-Driven Development for several reasons and benefits like:
- clarity
- scenarios focus on expected behaviours, which are described in plain language. Clarity ensures customers get what they want.
- automation
- BDD makes turning scenarios into automated tests easy
- inclusion
- it is all about collaboration, which means everybody from the customer to the tester is engaged in the product development process
- speed
- BDD was designed to speed up the development since scenarios are requirements, acceptance criteria, test cases and test scripts all in one.
- momentum
- BDD has a snowball effect - scenarios are easier and faster to write and automate as more definitions are added. They also often share common steps.
- shift left
- ‘shift left testing’ means testing earlier in the development process, which results in fewer bugs later.
- artefacts
- scenarios can form a collection of self-documenting test cases, which can be turned into a regression test suite.
- reusable code
- some of the steps can be reused between scenarios. Automation coded becomes very modular.
- test-driven
- BDD is an evolution of TDD. Creating scenarios from the beginning introduces quality-first and test-first mindset.
- variation
- with scenario outlines it is easy to run the same scenario with different combinations of inputs, which is an amazing way to expand test coverage without code duplication
- parameterization
- scenarios steps can be parametrized to be even more reusable. It is helpful for the team to adopt a common, reusable set of steps, which inspires healthier discussions when writing scenarios.
- adaptability
- BDD scenarios are easy to update as the product changes
Advantages of Gherkin
You might know the benefits of Behaviour-Driven development, but what about Gherkin? What are the advantages of using it? There are quite a few of them:
- simple even for non-programmers
- a solid base for tests
- it is easy to reuse code in other tests
- User Stories are simple to comprehend
- Gherkin Tests cases link acceptance tests directly to automated tests
- scripts can be easily understood by both business executives and developers
- Gherkin Testing targets business requirements
In my opinion, the most important advantage of Gherkin is understandability:
- It is simple for everyone to understand (QA’s, developers and people not associated with programming or software in general)
- Gherkin script can easily be understood by business executives and developers (basically the same as above)
- Little to no previous experience is required in order to understand a small Gherkin command set
What is more, using Gherkin means better communication, which leads to faster time-to-market and its test scenarios can be useful in many ways:
- As a simple documentation
- They help to track test automation coverage
- They can be used for test automation
Fun fact: Gherkin language uses only 10 keywords, which makes it super easy.
Gherkin test basics
Now let’s talk about Gherkin in practice. However, before you start writing, you should understand some Gherkin-related keywords:
Feature
Gherkin documents start with this keyword, preceded by text that provides a description. Simply put, a feature is a description of what the software should be doing. It is also used to group scenarios together. The file should have a `.feature` extension and each feature file should have only one feature.
Note: Free-form description can also be written below the keywords as long as none of the lines starts with a keyword.
Rule
The ‘rule’ keyword represents one business rule that has to be included as it provides context for a feature. Keep in mind that those rules should have more than one scenario.
Given
‘Given’ steps set the scene for the scenario. Most often they describe something that took place in the past. This gives the system context before users start interacting with it.
When
‘When’ means action steps. It describes an event like one triggered by another system or a user interacting with it. Note that it is recommended to have only one ‘when’ step for each scenario.
Then
‘Then’ is the outcome step. This is where you describe what the system is supposed to do. This should be something that can actually be seen as a result like a report or a message.
And, But
They can be used when you have several of one of the step types. They help to keep the documentation readable and organized. ‘But’ keyword can easily be replaced by a properly used ‘And’, which helps to keep the number of keywords as low as possible and provides consistency throughout the test scenario.
Background
The background allows adding more context to the scenarios in a ‘feature’. This is where you can provide more than one ‘given’ step.
Scenario Outline
This includes an examples section and can be read as a template. The scenario outline runs once for each of the example sections.
Summary
Behaviour-Driven Development is an amazing way to help your team communicate and collaborate better. As it focuses on the actual features’ behaviour it is great for testing APIs and web UIs. It helps to clarify requirements, discover new use-cases and make timely decisions. It also supports developers and encourages confidence.
Gherkin is one of the most popular languages for writing behaviour specifications as it captures the ‘Given-When-Then’ scenarios. What is more, it makes it easy to turn those scenarios into automated test cases and is easy to understand.
In the next post about Gherkin, we will go through the testing process and present how to write good tests, so keep your eyes peeled!
If you are looking for a team of developers that know how to work with BDD or Gherkin and can take care of your project from start to finish, you are in the right place. Feel free to contact Selleo to discuss your idea further, get to know the team and start the development now!
