BDD Cucumber Cheat Sheet

I. Gherkin Syntax (Feature Files)

Gherkin is the language used to write Cucumber feature files. It's a plain-text, human-readable language.

• Feature: Describes a high-level capability or business rule.

  Gherkin

    Feature: User Authentication
      As a user, I want to be able to log in
      So that I can access my personalized content
  

• Scenario: A concrete example illustrating a single behavior for the feature.

  Gherkin

    Scenario: Successful Login with Valid Credentials
      Given I am on the login page
      When I enter "test@example.com" as email and "password123" as password
      And I click the "Login" button
      Then I should be redirected to the dashboard
      And I should see a welcome message "Welcome, test@example.com!"
  

• Scenario Outline: Used for multiple examples of the same scenario, varying only the data.

  Gherkin

    Scenario Outline: Unsuccessful Login with Invalid Credentials
      Given I am on the login page
      When I enter "<email>" as email and "<password>" as password
      And I click the "Login" button
      Then I should see an error message "<error_message>"
  
      Examples:
        | email             | password  | error_message               |
        | invalid@example.com | wrongpass | Invalid email or password.  |
        |                   | password123 | Email field cannot be empty. |
        | test@example.com  |           | Password field cannot be empty. |
  

• Background: Steps run before each scenario in a feature. Use for common setup.

  Gherkin

    Background:
      Given I have an active internet connection
  

• Given: Describes the initial context or pre-conditions.

• When: Describes the action or event performed.

• Then: Describes the expected outcome or post-conditions.

• And/But: Used to combine multiple Given, When, or Then steps for readability.

• Tags: Used to group scenarios or features, often for selective execution.

  Gherkin

    @smoke @regression
    Scenario: ...
  

• Comments: Lines starting with # are comments.

II. Step Definitions (Programming Language Specific)

Step definitions link the Gherkin steps to executable code.

• General Structure:

  Code snippet

    // Example in Ruby with Cucumber
    Given('I am on the login page') do
      # Code to navigate to the login page
    end
  
    When('I enter {string} as email and {string} as password') do |email, password|
      # Code to input email and password
    end
  
    Then('I should be redirected to the dashboard') do
      # Code to verify redirection
    end
  
    // Example in Java with Cucumber JVM
    @Given("I am on the login page")
    public void i_am_on_the_login_page() {
        // Code to navigate to the login page
    }
  
    @When("I enter {string} as email and {string} as password")
    public void i_enter_as_email_and_as_password(String email, String password) {
        // Code to input email and password
    }
  
    @Then("I should be redirected to the dashboard")
    public void i_should_be_redirected_to_the_dashboard() {
        // Code to verify redirection
    }
  

• Parameterization: Use {string}, {int}, {float}, or custom regex to capture values from Gherkin steps.

• Data Tables: Gherkin tables can be passed to step definitions.

  Gherkin

    Scenario: Adding multiple products to cart
      Given the following products are available:
        | Product Name | Price | Quantity |
        | Laptop       | 1200  | 1        |
        | Mouse        | 25    | 2        |
      When I add these products to my cart
      Then my cart should contain the following items:
        | Product Name | Quantity | Subtotal |
        | Laptop       | 1        | 1200     |
        | Mouse        | 2        | 50       |
  

  How to handle in Step Definitions (conceptually):

  Code snippet

    // Ruby example for illustration
    Given('the following products are available:') do |table|
      table.hashes.each do |row|
        # Access row['Product Name'], row['Price'], etc.
      end
    end
  

III. Hooks (Programming Language Specific)

Hooks allow you to execute code before or after certain events.

• @Before: Runs before each scenario.

• @After: Runs after each scenario.

• @BeforeStep: Runs before each step.

• @AfterStep: Runs after each step.

• @BeforeAll / @AfterAll (or similar, depending on language/version): Runs once before/after all features.

• Tagged Hooks: Apply hooks only to scenarios with specific tags.

  Code snippet

    // Example in Java
    @Before("@web")
    public void setupWebDriver() {
        // Initialize WebDriver
    }
  
    @After("@web")
    public void teardownWebDriver(Scenario scenario) {
        // Take screenshot on failure, close browser
    }
  

IV. Running Cucumber

• Command Line:

  Bash

    cucumber # (or `mvn test`, `npm test` depending on project setup)
    cucumber features/my_feature.feature
    cucumber --tags @smoke
    cucumber --name "Successful Login"
  

• Configuration: Typically managed via cucumber.yml (Ruby), cucumber.properties (Java), or within your build tool (Maven, Gradle, package.json).

V. Best Practices

• Ubiquitous Language: Use terms from the domain, understood by both business and technical teams.

• Keep Scenarios Short and Focused: Each scenario should test one distinct behavior.

• Avoid Technical Details in Gherkin: Keep Gherkin readable and business-oriented. Push technical implementation into step definitions.

• DRY (Don't Repeat Yourself) for Step Definitions: Reuse steps as much as possible.

• Atomic Steps: Each step should do one thing.

• Meaningful Step Names: Use clear, descriptive names for your steps.

• Organize Feature Files: Group related features together in directories.

• Organize Step Definitions: Group related step definitions into logical files.

• Use Tags Effectively: For organizing, filtering, and running subsets of tests.

• Failing Tests First (Red-Green-Refactor): Write a failing scenario, write code to make it pass, then refactor.

• Cucumber is a Collaboration Tool: It's not just for automation; it's for clarifying requirements.

• Keep Step Definitions Lean: Delegate complex logic to supporting code or Page Objects (for UI automation).