We all relish sour, salty and crunchy pickled gherkins (Cucumbers) made by our grandma.
But, have you ever been “in a pickle” trying to understand how Gherkins and Cucumbers are related to the world of Software? Let’s find out in this article.
Before talking about Cucumber and Gherkins, let’s first understand about Behavior-Driven Development (BDD).
What is BDD?
Behavior-Driven Development is a way for software teams like Business Analysts, Developers and QA (Quality Assurance) to communicate, collaborate and build a shared understanding about the problem to be solved and thereby, bridge the gap between various cross-functional teams and build a better software.
BDD is a software development process which helps in refining the business requirements, detect problems at an early stage by using examples of system behavior and reach to a common understanding of the specifications.
BDD enhances the agile process followed by the teams and helps in delivering timely and reliable releases of working software.
What is Cucumber?
Cucumber is an open-source testing tool that supports Behavior Driven Development (BDD). It offers a way to write test cases that are easy to read and can be understood by anybody, regardless of their technical proficiency.
Cucumber Tool provides end-to-end testing framework and is a highly efficient tool for performing automation testing of web applications.
What is Gherkin?
Gherkin is simple, user-understandable language that is used to define the test cases in Cucumber framework. It consists of a set of grammar rules that makes plain text structured enough for Cucumber to understand.
Gherkin is a Business Readable, Domain-specific Language which allows Business Analysts to document acceptance tests in a language that developers, QA and the business can understand.
Gherkin scripts connect the human concept of cause and effect to the software concept of input, process and output.
Gherkin syntax uses a set of special keywords to give structure and meaning to the requirement specifications.
The list of primary keywords used in Gherkin language are:
Now, let us take a deep dive into understanding each of these Keywords in detail.
1. Feature: A Gherkin document typically starts with the keyword ‘Feature’.
Feature gives a high-level description about what the particular Requirement is all about.
Additionally, ‘Feature’ keyword is also used to group the Scenarios together.
For projects following Agile methodology, each Feature can be mapped to a User Story or an Epic.
2. Background: The ‘Background’ keyword is used to add some Pre-conditions that are required to be followed before executing the Scenarios. It is advisable to keep the Background section short and vivid.
3. Scenario: The ‘Scenario’ keyword describes the functionality that needs to be tested. It conveys what should be tested and how it can be tested. It includes all possible circumstances that can be tested.
The ‘Scenario’ Keyword is followed by Keywords like ‘Given’, ‘When’ and ‘Then’.
We can also use the keyword ‘Scenario Outline’ to run the same scenario multiple times, with different combinations of values. Furthermore, ‘Scenario Outline’ keyword can also be used to provide Examples of possible outcomes.
4. Given: The ‘Given’ keyword provides the initial context of the scenario. The main purpose of Given is to put the system in a known state before the user (or external system) starts interacting with the system.
5. When: The keyword ‘When’ is used to describe an action or an event. It is recommended to write only one ‘When’ step for each scenario.
6. Then: The keyword ‘Then’ is used to describe an expected outcome or result of the action that was performed.
The expected outcome should be an observable output like a message or a report.
7. And & But: The ‘And’ and ‘But’ keywords are used to combine two or more actions of the same type. These keywords help in making the scenario more readable and presentable.
Now, let’s see how a sample Gherkin looks like:
How is the Gherkin Document stored?
Gherkin documents are stored in text files with ‘.feature’ extension and they are known as ‘feature files’. They are typically versioned in source control along with the software.
What is Step Definition?
The Step Definition connects the Gherkins to the Programming code. The Step Definition file stores the mapping between each step of the scenario defined in the feature file with a code of function to be executed.
The following is the sample Step Definition for the above Gherkins:
Art of Writing Good Gherkins: It is important to write good and meaningful gherkins in order to achieve better throughput. So, we can write good Gherkins by keeping these below rules in mind.
1. Gherkin’s Golden Rule — This rule states that we have to treat other readers as we would want us to be treated. So, it implies that we need to write the gherkins in such a way that everyone can understand them.
2. The cardinal rule of BDD — This rule is a one-to-one rule. It means one scenario should cover exactly one single, independent feature.
3. The unique example rule — This rule says that it is better to exclude unnecessary examples and test only the most important things. Also, we can avoid testing duplicate things and save our precious time.
4. The good grammar rule — Poor grammar, spelling mistakes, bad formatting and inconsistent phrasing can ruin the benefits of writing gherkins. A good gherkin should be readable and clear. It shouldn’t be ambiguous or misleading.
Summing Up Gherkins and Cucumber improve team collaboration and hence, increase their overall productivity. Gherkins are easy to write and help in bridging the gap between stakeholders, developers and testers. So, let’s practice and excel in the art of writing good Gherkins by following the above discussed guidelines.
Happy learning and Happy Writing.