BDD – Framework Thinking

Software Engineering & Development Methodologies

BDD

Behavior-Driven Development

1. Overview of BDD: A Behavior-Driven Development Methodology That Embeds Collaboration and Quality Through Scenario Specifications

    flowchart LR
    A["Misunderstanding of requirements<br/>between developers and business<br/>tests written after the fact hurt quality"] --"Natural-language scenarios<br/>as a common language"--> B["Given-When-Then<br/>behavior-specification-driven development"] --"Executable specifications<br/>are automated"--> C["Requirements, code, and tests<br/>stay in sync"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: A development methodology that extends TDD to the business perspective. It specifies the behavior a system must exhibit as Given-When-Then natural-language scenarios readable by business stakeholders, and links these to automated tests — a collaboration-centered methodology that builds shared understanding among developers, QA, and business experts.

Characteristics: (Ubiquitous Language) Scenarios are written in a near-natural language such as Gherkin, so non-technical stakeholders can review them. (Executable specification) Scenarios connect directly to automated test code, so requirements, implementation, and tests always stay aligned. (Collaborative discovery) 3 Amigos (developer, QA, business) workshops resolve requirement ambiguity before development begins.

2. Core Structure of BDD

a. The Given-When-Then Scenario Specification

    flowchart TD
    subgraph GWT["Scenario Structure (Gherkin)"]
        direction TB
        GIV["Given (precondition)<br/>Defines the system's initial state<br/>sets up the environment before the test runs"]
        WEN["When (behavior trigger)<br/>Executes a specific action<br/>by the user or the system"]
        THN["Then (expected outcome)<br/>Verifies the result/state<br/>the system should show"]
        AND["And / But<br/>Additional description of<br/>conditions, actions, or results"]
        GIV --> WEN --> THN --> AND
    end

    style GIV fill:#E3F2FD,stroke:#1976D2,color:#000
    style WEN fill:#FFF3E0,stroke:#F57C00,color:#000
    style THN fill:#E8F5E9,stroke:#388E3C,color:#000
    style AND fill:#F3E5F5,stroke:#7B1FA2,color:#000

Example Gherkin Scenario

Feature: Online store shopping cart management

  Scenario: Add an in-stock item to the cart
    Given the customer is logged in
    And   the product "Wireless Keyboard" has 10 units in stock
    When  the customer adds 2 units of "Wireless Keyboard" to the cart
    Then  the cart should contain 2 units of "Wireless Keyboard"
    And   the stock should decrease to 8 units

  Scenario: Show an error when requesting more than available stock
    Given the product "Wireless Keyboard" has 1 unit in stock
    When  the customer tries to add 3 units of "Wireless Keyboard"
    Then  an "insufficient stock" error message should be shown

Detail of the Given-When-Then Components

Element	Role	Code Mapping	Writing Principle
Feature	Describes the business purpose of the feature under test	A test file unit	Written from a user-value perspective
Scenario	One concrete use case	A test method unit	Must be independent and reproducible
Given	Sets the initial state before the scenario runs	`@Before` / setUp	Describe only the minimum necessary state
When	Executes the behavior/event under test	Actual action invocation	Describe a single action (avoid multiple)
Then	Specifies the verification conditions for the expected result	`assert` / `expect`	State clearly as a measurable outcome
And / But	Continuation of the preceding keyword	Continues the same role	Used to improve readability

b. Collaborative Requirements Discovery and Automation

    flowchart LR
    subgraph DISCOVERY["Discovery"]
        direction TB
        D1["3 Amigos workshop<br/>developer, QA, and business<br/>jointly derive requirement scenarios"]
        D2["Example Mapping<br/>surface edge cases via<br/>rules, examples, and questions"]
    end

    subgraph FORMULATION["Formulation"]
        direction TB
        F1["Write Gherkin scenarios<br/>document the natural-language spec<br/>stakeholder review & approval"]
    end

    subgraph AUTOMATION["Automation"]
        direction TB
        A1["Implement step definitions<br/>Cucumber, Behave, SpecFlow<br/>connect scenarios to executable code"]
        A2["Integrate into the CI/CD pipeline<br/>run automated tests<br/>build a regression-prevention system"]
    end

    DISCOVERY --> FORMULATION --> AUTOMATION

    style DISCOVERY  fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
    style FORMULATION fill:#FFF3E0,stroke:#F57C00,color:#7C3700
    style AUTOMATION fill:#E8F5E9,stroke:#388E3C,color:#1B5E20

Key BDD Tool Stack

Tool	Language	Role	Characteristics
Cucumber	Java, Ruby, JS	Runs Gherkin scenarios	Most widely used, supports multiple languages
Behave	Python	BDD for the Python environment	Integrates easily with Django/Flask
SpecFlow	C# (.NET)	BDD for the .NET environment	Visual Studio integration
Jest + Cucumber	TypeScript	Node.js frontend	Integrates with React/Angular testing
Playwright BDD	JS/TS	E2E BDD testing	Browser automation scenarios

TDD vs. BDD Comparison

Comparison	TDD	BDD
Focus	Behavior of code units (methods, classes)	System behavior and business scenarios
Written by	Developers	Developers, QA, and business collaboratively
Language	Programming language	Gherkin, close to natural language
Test unit	Unit tests	Acceptance tests, functional tests
Relationship	The inside of a BDD scenario is implemented using TDD

3. Expected Benefits and Application of BDD

Category	Expected Benefits	Application and Practical Use
Requirements quality	Removing ambiguity before development minimizes rework and misunderstanding costs	Turn acceptance criteria (AC) into scenarios via 3 Amigos workshops before sprint kickoff
Collaboration efficiency	Non-technical stakeholders can directly review and approve test scenarios	Use feature files as a Living Specification
Test automation	Scenarios are the test code — requirements and implementation always stay in sync	Integrate a BDD scenario execution gate into the CI/CD pipeline
Regression prevention	Behavior-based tests instantly detect the impact of feature changes	Manage defect patterns by analyzing failed scenarios during sprint retrospectives

TDD / BDD DevOps