Behavior-Driven Development (BDD)

Behavior-Driven Development (BDD) is an agile software development process that encourages collaboration among developers, QA, and non-technical or business participants in a software project. It evolved from Test-Driven Development (TDD) by focusing on the behavior of the system from the user’s perspective.

The Core Concept

While TDD focuses on how a unit of code works, BDD focuses on what the system does for the user. It uses a domain-specific language (DSL) that is readable by both technical and non-technical stakeholders.

Collaborative BDD: The “Three Amigos”

BDD is as much about communication as it is about automation. The “Three Amigos” is a practice where three key perspectives meet to discuss a requirement before it is implemented:

1. Business (Product Owner): What problem are we solving?
2. Development: How will we implement the solution?
3. Testing (QA): What about the edge cases? What could go wrong?

This collaboration results in a shared understanding and a set of concrete examples that form the basis of the Gherkin scenarios.

Specification by Example (SBE)

BDD is often implemented through Specification by Example. Instead of abstract requirements, the team uses concrete examples of the system in action.

• Requirement: “The system should calculate discount for bulk orders.”
• Example: “Given a user adds 10 items to the cart, when they check out, a 5% discount should be applied.”

Gherkin Syntax: Given / When / Then

BDD scenarios are often written in Gherkin, a plain-text language that follows a specific structure:

• Feature: A high-level description of a software feature.
• Scenario: A specific example illustrating how the feature should behave.
• Given: The initial context or “preconditions.”
• When: The action taken by the user or the event that occurs.
• Then: The expected outcome or “postconditions.”

Example Scenario (Cucumber/Gherkin)

Feature: User Login
  As a registered user
  I want to log into my account
  So that I can access my personalized dashboard

  Scenario: Successful login with valid credentials
    Given I am on the login page
    When I enter "john.doe@example.com" in the email field
    And I enter "password123" in the password field
    And I click the "Login" button
    Then I should be redirected to the dashboard
    And I should see a welcome message "Welcome, John!"

Step Definitions (JavaScript with Cucumber.js)

The scenarios in Gherkin are mapped to “Step Definitions” in code.

const { Given, When, Then } = require('@cucumber/cucumber');
const assert = require('assert');

Given('I am on the login page', async function () {
  await browser.url('/login');
});

When('I enter {string} in the email field', async function (email) {
  await browser.setValue('#email', email);
});

When('I enter {string} in the password field', async function (password) {
  await browser.setValue('#password', password);
});

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

Then('I should be redirected to the dashboard', async function () {
  const url = await browser.getUrl();
  assert.strictEqual(url.includes('/dashboard'), true);
});

Benefits of BDD

1. Shared Understanding: Eliminates the “lost in translation” problem between business owners and developers.
2. Living Documentation: The features themselves serve as documentation that is always in sync with the code.
3. Customer Focus: Ensures that the development team is building features that provide actual value to the user.
4. Early Automation: Encourages writing acceptance tests early in the development lifecycle.

BDD vs. TDD

BDD doesn’t replace TDD; they are complementary. TDD ensures the code is built right, while BDD ensures the right system is built.