# Gherkin
Gherkin is a simple, human-readable language used to write behavior specifications in Behavior-Driven Development (BDD). It uses a structured format with keywords like Given, When, and Then to describe software features and scenarios, making them understandable to both technical and non-technical stakeholders.
**Pronunciation:** gur-kin
**Difficulty:** Beginner
**Synonyms:** BDD Syntax, Cucumber Language, Specification Language
**Categories:** Software Development, Testing, Agile Methodologies
**Tags:** BDD, Specification by Example, Cucumber, Testing Framework, DSL, Agile
Canonical: https://scaleengineer.com/glossaries/gherkin
---
## Definitions

- **Gherkin in Behavior-Driven Development (BDD):** Gherkin is a business-readable, Domain-Specific Language (DSL) designed to describe software's behavior without detailing its implementation. It is a cornerstone of Behavior-Driven Development (BDD), acting as a bridge between business requirements and technical execution.

The primary goal of Gherkin is to foster collaboration among team members, including developers, testers, business analysts, and product owners. By using a plain language format, it ensures that everyone has a shared understanding of the system's intended behavior, creating what is often called "living documentation."

**Key Structure and Keywords**

Gherkin syntax is built around a set of keywords that provide a clear and consistent structure to behavioral specifications, which are saved in files with a `.feature` extension.

*   **Feature**: A high-level description of a software feature.
*   **Scenario** (or **Example**): A concrete example illustrating a single business rule within the feature.
*   **Given**: Describes the initial context or precondition. It sets the stage for the test.
*   **When**: Describes an action performed by the user or an event that occurs.
*   **Then**: Describes the expected outcome or result. This is the assertion part of the test.
*   **And**, **But**: Used to chain multiple steps under a `Given`, `When`, or `Then` to improve readability without being repetitive.
*   **Background**: Defines a set of `Given` steps that are common to all scenarios in a feature file, reducing duplication.
*   **Scenario Outline**: A template for running the same scenario with multiple sets of data, useful for data-driven testing.
*   **Examples**: A table of data that accompanies a `Scenario Outline`, where each row represents a run of the scenario.

**Example Gherkin File**

```gherkin
Feature: User Authentication
  As a user
  I want to log in to the application
  So that I can access my personalized content

  Scenario: Successful login with valid credentials
    Given I am on the login page
    When I enter my username "testuser" and password "password123"
    And I click the "Login" button
    Then I should be redirected to the dashboard
```

**How It Works**

Tools like Cucumber, SpecFlow, or Behave parse these `.feature` files. Each line (or step) in a Gherkin scenario is mapped to a corresponding block of code called a "step definition." This code contains the actual logic to interact with the application and verify the outcomes. This separation allows the specifications to remain clean and readable while the underlying implementation can be complex.

## Etymology

The name 'Gherkin' is a playful nod to 'Cucumber,' the most popular software tool that uses it. A gherkin is a small variety of cucumber, often pickled. This naming reflects the close relationship between the language (Gherkin) and the tool that processes it (Cucumber).

## First used

2007

## Historical context

Gherkin's origins are deeply tied to the rise of Behavior-Driven Development (BDD), an agile software development practice that evolved from Test-Driven Development (TDD). In the mid-2000s, developers sought better ways to connect tests to business requirements.

Around 2006, Dan North formalized the concepts of BDD, emphasizing the use of a shared, ubiquitous language to describe system behavior. He proposed a template: "Given a certain context, When an event occurs, Then an outcome should be observed."

In 2007, Aslak Hellesøy, inspired by Dan North's work and Specification by Example, created the tool Cucumber. He needed a simple, structured yet human-readable language to write these behavioral specifications. This language became Gherkin. It provided a formal grammar for the Given-When-Then structure, making it possible for a machine to parse the specifications and execute them as automated tests.

The creation of Gherkin was a pivotal moment for BDD. It provided the practical syntax needed to turn the theory of collaborative specification into a reality, enabling teams to create a single source of truth that served as both requirements and executable tests.

## Q&A

- **What is the primary purpose of the Given-When-Then structure in Gherkin?:** The Given-When-Then structure provides a clear and consistent format for describing behavior. **Given** establishes the initial state or context before an action occurs. **When** describes the specific action or event being tested. **Then** specifies the expected outcome or result of that action. This structure makes scenarios easy to read, understand, and automate.
- **How does Gherkin facilitate collaboration between technical and non-technical team members?:** Gherkin uses a plain, natural language syntax that is accessible to everyone, including business analysts, product owners, and testers, not just developers. This allows non-technical stakeholders to read, understand, and even write behavioral specifications. It creates a shared language and a single source of truth for requirements, reducing misunderstandings and ensuring the final product aligns with business goals.
- **What is the difference between a Scenario and a Scenario Outline in Gherkin?:** A **Scenario** describes a single, concrete example of a business rule. A **Scenario Outline** is a template that allows you to run the same scenario multiple times with different sets of data. The data is provided in a table under the **Examples** keyword, making it efficient to test various inputs and edge cases without duplicating the scenario steps.

## Usage examples

- Our team writes **Gherkin** scenarios to define acceptance criteria before starting development.
- The product owner reviewed the **BDD Syntax** in the `.feature` file to ensure it accurately reflected the user story's requirements.
- To automate the tests, the developer needs to implement step definitions for each line in the **Gherkin** script.
- Using the **Cucumber Language** helps us create living documentation that is easily understood by both technical and non-technical stakeholders.

## Related terms

- Behavior-Driven Development (BDD)
- Cucumber
- Test-Driven Development (TDD)
- Specification by Example (SBE)
- Domain-Specific Language (DSL)
- Acceptance Criteria

## Popular related terms

- Behavior-Driven Development (BDD)
- Cucumber
- Given-When-Then