Module 4 — BDD with Cucumber

Learning Objectives

By the end of this module, you will be able to:

• Write human-readable test scenarios using Gherkin syntax
• Implement step definitions in JavaScript
• Map stakeholder requirements directly to code
• Run Cucumber in a Node.js environment

What is Behavior-Driven Development (BDD)?

BDD is an extension of TDD. While TDD focuses on the implementation (e.g., "does this function return the correct array?"), BDD focuses on the behavior from the user's perspective (e.g., "can a user filter products by category?").

The core tool for BDD in the JavaScript ecosystem is Cucumber.

Gherkin Syntax

Gherkin is a Domain-Specific Language (DSL) that allows you to write test scenarios in plain English. These are saved in .feature files.

The syntax uses specific keywords: Feature, Scenario, Given, When, and Then.

gherkin
# features/login.feature
Feature: User Login
  As a registered user
  I want to log in to my account
  So that I can access my dashboard

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters "alice@example.com" and "password123"
    And clicks the login button
    Then they should be redirected to the dashboard
    And see a welcome message

This file serves as living documentation. A Product Manager can read, write, and approve this file without knowing any JavaScript.

Step Definitions

A .feature file does nothing on its own. It needs "Step Definitions" — JavaScript code that tells Cucumber what to do when it encounters a specific step.

javascript
// steps/login.steps.js
const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai'); // Cucumber works well with Chai
const browser = require('../lib/browser'); // Hypothetical browser utility

Given('the user is on the login page', async function () {
  await browser.navigateTo('/login');
});

// We use regular expressions or Cucumber Expressions to capture variables
When('the user enters {string} and {string}', async function (email, password) {
  await browser.fillInput('#email', email);
  await browser.fillInput('#password', password);
});

When('clicks the login button', async function () {
  await browser.click('#submit-btn');
});

Then('they should be redirected to the dashboard', async function () {
  const currentUrl = await browser.getCurrentUrl();
  expect(currentUrl).to.include('/dashboard');
});

When you run Cucumber, it matches the Gherkin text to the JavaScript step definition and executes it.

Stakeholder Collaboration

The true power of BDD is not technical; it is communicative.

A common BDD workflow:

1. Discovery: PM, QA, and Developers discuss a feature.
2. Formulation: They collaboratively write a .feature file (the "Three Amigos" meeting).
3. Automation: Developers write the step definitions to automate the feature file.
4. Development: Developers write the application code until the feature passes.

This ensures that the engineering team builds exactly what the product team requested, with an automated test to prove it.

Key Takeaways

• BDD bridges the gap between technical and non-technical stakeholders.
• Gherkin feature files act as living, executable documentation.
• Step definitions map plain English requirements to automated assertions.
• The "Three Amigos" process ensures testing happens at the requirement phase.

Knowledge Check

Question 1: A Product Manager writes a new feature request: "Users should be able to reset their password using an email link." The engineering team decides to use Behavior-Driven Development (BDD). What is the most correct immediate next step in the BDD workflow?

• A) The frontend team builds the password reset form while the backend team builds the API, and then QA writes Cypress tests to verify it works.
• B) Developers write unit tests (TDD) for the PasswordResetService to ensure the core logic is covered before any UI is built.
• C) The Product Manager, QA, and Developers meet (the "Three Amigos") to collaboratively write a .feature file in Gherkin syntax detailing the exact password reset scenarios.
• D) The engineering team writes JavaScript step definitions using @cucumber/cucumber to automate the browser interactions required for a password reset.

Question 2: In a Gherkin .feature file, you write the following scenario step: When the user enters "admin" and "supersecret". How does the Cucumber framework know what code to execute when it reads this line?

• A) Cucumber uses natural language processing (NLP) to automatically deduce that it needs to find HTML inputs named admin and supersecret and fill them.
• B) A developer must write a JavaScript "Step Definition" that uses a string or regular expression to match the Gherkin text and captures the values as function arguments.
• C) Cucumber parses the .feature file and directly compiles the When statement into an equivalent Cypress cy.get().type() command based on an internal dictionary.
• D) The .feature file must be imported into a Jest it() block, and the developer must manually call the Gherkin string as a function.

Question 3: What is the primary functional difference between Test-Driven Development (TDD) and Behavior-Driven Development (BDD)?

• A) TDD requires tests to be written before the code, whereas BDD allows tests to be written after the code is deployed to production.
• B) TDD is used exclusively for backend development (Node.js/APIs), while BDD is used exclusively for frontend development (React/Browser).
• C) TDD focuses on the internal technical implementation and API contracts of the code, while BDD focuses on the external system behavior from the perspective of the end user.
• D) TDD uses Jest as its runner, whereas BDD requires Selenium to execute scenarios.

BDD tests often require a browser to execute user scenarios. In the next module, we will explore the modern tools used to drive browsers and simulate real user journeys: Playwright and Cypress.

Next: Module 5 — End-to-End Testing →