Gherkin is a domain-specific language (DSL) used in Cucumber to define test scenarios in a human-readable format. It allows stakeholders, developers, and testers to collaborate by describing application behavior in plain English. Gherkin uses keywords to structure feature files, ensuring clarity and consistency.

📌 Gherkin Keywords

Keyword Description
Feature Defines the high-level functionality being tested
Scenario Represents a single test case
Scenario Outline Allows data-driven testing using multiple test cases
Examples Provides test data for Scenario Outline
Given Defines the preconditions for a scenario
When Represents an action performed by the user
Then Defines the expected outcome or validation
And / But Used for better readability to extend Given/When/Then steps
Background Defines common preconditions for multiple scenarios
Rule Groups multiple scenarios under a business rule
Comments (#) Adds notes or explanations in the feature file

1️⃣ Feature

The Feature keyword represents the high-level functionality or business requirement being tested. It acts as a headline for the test scenarios and provides an overview of what is being verified.

  • Represents the high-level description of a functionality.
  • Every feature file starts with a Feature keyword.
  • Contains multiple scenarios.

    • Syntax:

    Feature: Login Functionality

    Explanation:

    • Every feature file must start with the Feature keyword.
    • It should provide a brief description of the functionality being tested.
    • A feature file can contain multiple scenarios that describe different test cases related to the feature.

    Example:

    Feature: User Login  
  Users should be able to log in using valid credentials.

    2️⃣ Scenario

    A Scenario represents a single test case within a feature. It follows the Given-When-Then structure to describe test steps in a structured manner.

  • Represents a single test case.
  • Follows a Given-When-Then structure.

    • Syntax:

    Scenario: Successful login with valid credentials

    Explanation:

    • Each Scenario describes a specific test case with a well-defined flow.
    • It consists of steps using Gherkin keywords (Given, When, Then, And, But).
    • Each scenario is independent and should be self-contained.

    Example:

    Scenario: Successful login with valid credentials  
  Given the user is on the login page  
  When the user enters a valid username and password  
  Then the user should be redirected to the homepage

    3️⃣ Scenario Outline

    The Scenario Outline keyword is used when the same scenario needs to be executed multiple times with different sets of input data. It helps in data-driven testing by avoiding repetition.

  • Used for data-driven testing.
  • Allows multiple test cases with different inputs.

    • Syntax:

    Scenario Outline: <Scenario Name>

    Explanation:

    • It works with the Examples table, where placeholders (<parameter>) are replaced with actual values.
    • The test case runs once for each row in the Examples table.

    Example:

    Scenario Outline: Login with multiple credentials  
  Given the user is on the login page  
  When the user enters "<username>" and "<password>"  
  Then the login should be "<status>"  

Examples:  
  | username  | password  | status  |  
  | user1     | pass123   | success |  
  | user2     | wrongpass | failure |

    📌 How It Works:

    • <username> and <password> are placeholders.
    • Cucumber will execute the scenario twice—once for each row in Examples.

    4️⃣ Given, When, Then, And, But

    🔹 Given (Precondition)

    The Given step sets up the initial state of the system before the main action occurs.

  • Represents the preconditions or setup.
  • Describes the initial state before an action happens.

    • Example:

    Given the user is on the login page

    ✔ Used for preconditions such as navigation or existing data.

    🔹 When (Action/Trigger)

    The When step describes the user action that triggers a change in the system.

    Example:

    When the user enters valid credentials

    ✔ Represents events or interactions (e.g., clicking a button, submitting a form).

    🔹 Then (Expected Outcome)

    The Then step defines the expected outcome after performing an action.

    • Represents the expected outcome or assertion.

    Example:

    Then the user should be redirected to the homepage

    ✔ Used for assertions or verification of system behavior.

    🔹 And / But (Additional Conditions)

    • Used for better readability in Gherkin steps.
    • And extends the Given, When, Then steps.
    • But defines negative conditions.

    Example:

    Given the user is logged in  
And the user is on the homepage  
When the user searches for "Laptop"  
Then search results should be displayed  
But out-of-stock products should not appear

    📌 Purpose: Improves readability and avoids repeating Given, When, or Then.

    5️⃣ Examples

    The Examples keyword is used with Scenario Outline to provide multiple sets of test data for a scenario.

  • Provides test data for a Scenario Outline.
  • Written in table format.

    • Syntax:

    Examples:
  | Column1  | Column2  |
  | Value1   | Value2   |

    Example:

    Scenario Outline: Login with multiple users  
  Given the user is on the login page  
  When the user enters "<username>" and "<password>"  
  Then the login should be "<status>"  

Examples:
  | username | password  | status  |
  | admin    | admin123  | success |
  | guest    | wrongpass | failure |

    📌 Purpose: Reduces redundancy by allowing multiple test cases with different values.

    6️⃣ Background

    The Background keyword is used to define common preconditions that are required for all scenarios within a feature.

  • Used for common preconditions shared across multiple scenarios.
  • Helps in reducing redundancy in feature files.

    • Syntax:

    Background:
  Given <Common Precondition>

    Explanation:

    • The Background section runs before each scenario in the feature file.
    • Helps avoid repeating common setup steps in every scenario.

    Example:

    Feature: Shopping Cart Functionality  

Background:
  Given the user is logged in  
  And the user is on the homepage  

Scenario: Adding an item to the cart  
  When the user searches for "Laptop"  
  And adds it to the cart  
  Then the cart should display "1 item"  

Scenario: Removing an item from the cart  
  When the user removes an item from the cart  
  Then the cart should be empty

    📌 Why Use Background?
    ✔ Reduces redundancy in feature files.
    ✔ Ensures consistent test setup for all scenarios.

    7️⃣ Rule

    Used to group multiple scenarios under a specific business rule.

    ✅ Example:

    Rule: Password requirements

Scenario: User sets a valid password
  Given the user is on the password reset page
  When they enter a password with at least 8 characters
  Then they should see a success message

    8️⃣ Comments (#)

    Used to add notes in a feature file.

    ✅ Example:

    # This is a comment
Scenario: Successful login
  Given the user is on the login page
  When they enter valid credentials
  Then they should be redirected to the dashboard

    🛠️ Best Practices for Writing Gherkin Scripts

    ✔ Write clear and concise scenarios
    ✔ Use Given-When-Then structure properly
    ✔ Avoid technical implementation details
    ✔ Use Background to remove redundant steps
    ✔ Use Scenario Outline for data-driven tests

    Conclusion

    🔹 Feature describes a high-level functionality.
    🔹 Scenario defines a single test case.
    🔹 Scenario Outline enables data-driven testing with multiple inputs.
    🔹 Given-When-Then provides a structured test flow.
    🔹 Examples help execute test cases with different data.
    🔹 Background prevents repetitive preconditions across multiple scenarios.

    By using these Gherkin keywords effectively, test scenarios become clear, reusable, and maintainable, making automated testing in Cucumber efficient. 🚀