Gherkin is a language used for writing user stories in a business-readable and software-understandable format. It is used in the Behavior Driven Development (BDD) methodology, where software is developed by defining and verifying its behaviour through automated tests.

Gherkin allows stakeholders to write user stories in a simple and understandable language, which can then be translated into automated tests. This helps to ensure that the software meets the business requirements and that all stakeholders have a shared understanding of the software's behaviour.

Gherkin uses a structure of keywords and indentation to describe the behaviour of a system. The keywords include "Feature", "Scenario", "Given", "When", "Then", "And", "But", "Background", and "Scenario Outline". These keywords provide a structure for writing user stories and help to ensure that the stories are written in a consistent and readable manner.

Gherkin also supports parameterization through the use of placeholders and examples, which allow you to write reusable scenarios with different inputs and outputs.

1. Given is used to set the initial context for the scenario.

2. When is used to describe the action the user takes.

3. Then is used to describe the expected outcome or result.

4. And and But can be used to continue the previous step and make the sentences more readable.

Here are some reasons why you may not want to use Gherkin:

1. When the stakeholders are not familiar with BDD or Gherkin: Gherkin is a language that is specific to BDD and may not be familiar to all stakeholders. If the stakeholders are not familiar with BDD or Gherkin, it may be difficult to use Gherkin to write user stories.

2. When the requirements are too complex: Gherkin is designed to be simple, but some requirements may be too complex to be expressed using Gherkin. In these cases, it may be more appropriate to use a different method to describe the requirements.

3. When the software development process is not compatible with BDD: Gherkin is designed to be used in a BDD process, where the software is developed by defining and verifying its behaviour through automated tests. If the software development process is not compatible with BDD, it may not be appropriate to use Gherkin.

4. When the stakeholders are not comfortable with automated testing: Gherkin is designed to be used in combination with automated testing, but some stakeholders may not be comfortable with this approach. If the stakeholders are not comfortable with automated testing, it may not be appropriate to use Gherkin.

Best Practices

These are considered best practices because they help to make the Gherkin scenarios clear, concise, and understandable to a broad range of stakeholders, including developers, testers, business analysts, and project managers.

Keeping each step brief and focused

This helps to reduce the complexity of the scenario, making it easier to read and understand.

Here's an example of keeping each step brief and focused in Gherkin:

Scenario: Login to the website
Given the user is on the login page
When the user enters a valid username and password
And clicks the login button
Then the user should be redirected to the homepage
And the username should be displayed on the top right corner

Each step is concise and focused on a single action or expected outcome, making it easier to understand what the scenario is testing and what the expected results are.

Using plain language

By avoiding technical terms, the scenario becomes more accessible to a wider range of stakeholders, including non-technical individuals.

Here's a good example of using plain language in Gherkin:

Scenario: Add a product to the cart
Given the user is on the product page
When the user selects a size and color
And clicks the add to cart button
Then the product should be added to the cart
And the user should see a confirmation message

And here's a bad example using technical language:

Scenario: Add a product to the cart
Given the user is on the PDP
When the user manipulates the DOM to select the SKU
And invokes the addToCart() function
Then the item should be appended to the cart object
And the user should observe a toast notification

The good example uses simple language that is easy to understand, while the bad example uses technical terms that may not be familiar to everyone.

Consistent use of keywords

This helps to maintain the structure and readability of the scenario.

Here's an example of consistent use of keywords in Gherkin:

Scenario: Book a flight
Given the user is on the flight booking website
When the user selects a departure and arrival city
And chooses the date of travel
And selects the number of passengers
And clicks the search button
Then the user should see a list of flights
And the user should be able to select a flight
And make a booking by entering passenger details and payment information

In this example, the keywords "Given", "When", "And", and "Then" are used consistently, making the scenario easy to follow and understand. Additionally, "And" is used to connect steps in a logical and readable manner.

Here's a bad example of inconsistent use of keywords in Gherkin:

Scenario: Book a flight
Given the user is on the flight booking site
And the user selects departure and arrival cities
When the dates are chosen
But the number of passengers are selected
Then the search button should be clicked
And a list of flights should appear
But the user can choose a flight
And enter passenger details and payment info to book

In this example, the keywords are used inconsistently, switching between "And" and "But", making the scenario difficult to follow and understand. This can lead to confusion and miscommunication among stakeholders. It's important to maintain consistent use of keywords to ensure the readability and clarity of the scenarios.

Use of background

The background is a way to set up the common context for multiple scenarios, reducing duplicated information and making the feature file more readable.

In Gherkin, the "Background" section is a way to provide a common context for multiple scenarios in a single feature file. The steps in the Background section are executed before each scenario in the same feature file. This allows you to set up shared preconditions that can be used in multiple scenarios, reducing duplicated information and making the feature file more readable.

Here's an example:

Background:
Given the user is on the flight booking website

Scenario: Search for a flight
When the user selects a departure and arrival city
And chooses the date of travel
And selects the number of passengers
And clicks the search button
Then the user should see a list of flights

Scenario: Book a flight
When the user selects a flight from the list
And clicks the book button
Then the user should be taken to the booking page
And the user should be able to enter passenger details and payment information

In this example, the Background section sets the initial context for both scenarios, reducing the need to repeat the "Given the user is on the flight booking website" step in each scenario.

Use of Scenario Outlines

This allows you to reuse the same scenario structure for multiple sets of data, reducing the need to write multiple scenarios with similar structures but different values.

The "Background" section and "Scenario Outlines" both provide ways to reuse steps and reduce duplicated information in Gherkin.

The "Background" section sets up the common context for multiple scenarios in a single feature file, while a "Scenario Outline" provides a template for multiple scenarios that differ only in the values used for specific parameters.

Here's an example of a Scenario Outline:

Scenario Outline: Search for flights
Given the user is on the flight booking website
When the user selects a departure city of "<departure>"
And selects an arrival city of "<arrival>"
And chooses the date of travel "<date>"
And selects the number of passengers "<passengers>"
And clicks the search button
Then the user should see a list of flights

Examples:
| departure | arrival | date | passengers |
| New York | London | 01/01/2023 | 2 |
| London | New York | 02/01/2023 | 4 |
| Paris | Rome | 03/01/2023 | 3 |

In this example, the "Scenario Outline" provides a template for multiple scenarios with different combinations of departure city, arrival city, date, and several passengers. The values for these parameters are specified in the "Examples" section, and a separate scenario is generated for each row in the table. This allows you to reuse the same steps for multiple scenarios while still testing different combinations of values.