Behavior-Driven Development

Description
A collaborative specification methodology that defines system behavior in natural language scenarios, bridging business intent and machine-verifiable acceptance criteria.
Status
Live
Last Updated
Tags
Testing, Specification, Agile, Requirements
Related
gherkin , learning-loop , context-engineering , spec-driven-development , the-spec , context-gates

Definition

Behavior-Driven Development (BDD) is a collaborative specification methodology that defines system behavior in natural language scenarios. It synthesizes Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD), emphasizing the “Five Whys” principle: every user story should trace to a business outcome.

The key evolution from testing to BDD is the shift from “test” to “specification.” Tests verify correctness; specifications define expected behavior. In agentic workflows, this distinction matters because agents need to understand what behavior is expected, not just what code to write.

Key Characteristics

From Tests to Specifications of Behavior

AspectUnit Testing (TDD)Behavior-Driven Development
Primary FocusCorrectness of code at unit levelSystem behavior from user perspective
LanguageCode-based (Python, Java, etc.)Natural language (Gherkin)
StakeholdersDevelopersDevelopers, QA, Business Analysts, POs
SignalPass/Fail on logicAlignment with business objectives
Agent RoleMinimal (code generation)Central (agent interprets and executes behavior)

The Three Roles in BDD

BDD emphasizes collaboration between three perspectives:

  1. Business — Defines the “what” and “why” (business value, user outcomes)
  2. Development — Defines the “how” (implementation approach)
  3. Quality — Defines the “proof” (verification criteria)

In agentic development, the AI agent often handles Development while Business and Quality remain human-defined. BDD provides the structured handoff format.

BDD in the Probabilistic Era

Traditional BDD was designed for deterministic systems: given specific inputs, expect specific outputs. Agentic systems are probabilistic—LLM outputs vary based on context, temperature, and emergent behavior.

BDD adapts to this by:

  • Defining behavioral contracts rather than implementation details
  • Allowing agents to determine how to achieve specified behavior
  • Providing semantic anchors that constrain the reasoning space without over-specifying

ASDLC Usage

BDD’s value in agentic development is semantic anchoring. When an agent is given a Gherkin scenario, it receives a “specification of behavior” that:

  • Partitions the reasoning space into manageable segments (Given/When/Then)
  • Defines success criteria without over-specifying implementation
  • Aligns technical execution with business intent

This is why BDD scenarios belong in Specs, not just test suites. They’re not just verification artifacts—they’re functional blueprints that guide agent reasoning.

Implementation via the Spec Pattern:

BDD ComponentSpec Implementation
Feature descriptionSpec Context section
Business rulesBlueprint constraints
Acceptance scenariosContract section (Gherkin scenarios)

Applied in:

  • The Spec — Implements BDD through Blueprint (constraints) and Contract (scenarios)
  • Context Gates — BDD scenarios define verification criteria at gates

References

  1. Dan North (2006). Introducing BDD . Accessed January 12, 2026.

    Original formulation of Behavior-Driven Development by its creator.

  2. Agile Alliance . Behavior Driven Development . Accessed January 12, 2026.

    Industry-standard glossary definition from the Agile Alliance.