Behavior-Driven Development

Develop software through collaborative discovery of concrete behavior examples that become shared, automatable specifications linking business intent to observable system outcomes.

Version

v3 · 2026-09-19 · History

Domain-specific #

1365

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomains

Software Engineering, Agile Software Development → Computer Science & Software Engineering

Aliases

Behaviour-Driven Development, BDD

Core Idea

Behavior-Driven Development (BDD) is a software-development practice in which product, development, and testing participants discover desired behavior together through concrete examples, record those examples in a shared readable form, and connect them to executable checks of the evolving system. The unit of alignment is not an internal function or a test method; it is an observable example of how the system should behave in a meaningful context.

Dan North introduced BDD as a reframing of test-driven development around behavior, using names and sentences that make the intent of code and tests easier to discuss.

How would you explain it like I'm…

Examples First, Then Build

Before building a new part of a computer program, the people who want it and the people who build it sit together and tell little stories, like 'When I press this button, my picture gets saved.' They write the stories down so everyone understands them. Then the computer uses those same stories to check that the program really does what everyone agreed.

Building From Agreed Examples

Behavior-Driven Development is a way of making software where everyone involved, the people who want it, the builders and the testers, first talks through real examples of how it should act. For example: 'Given I have 5 coins, when I buy a 2-coin snack, then I should have 3 coins left.' They write these examples in a form both people and computers can read. The examples guide the building, and they're turned into automatic checks that show whether the program behaves as agreed. Just writing examples in that format isn't enough; the important part is the team working out the behavior together.

Example-Driven Shared Specification

Behavior-Driven Development (BDD) is a software practice in which product, development, and testing people discover desired behavior together through concrete examples. Those examples are recorded in a readable shared form and connected to executable checks that run against the evolving system. The focus isn't on internal functions but on observable behavior in a meaningful situation. Dan North introduced it as a reframing of test-driven development around behavior and clearer naming. The familiar Given-When-Then format, used by tools like Cucumber, is one way to write examples, but it isn't the whole idea: a folder of such files without real collaboration isn't BDD, and BDD can happen without those tools.

 

Behavior-Driven Development (BDD) is a collaborative software-development practice in which product, development and testing participants discover desired behavior through concrete examples, capture those examples in a shared human-readable form, and bind them to executable checks of the evolving system. Its unit of alignment is an observable example of system behavior in context, not an internal function or a test method. Dan North introduced BDD as a behavior-centered reframing of test-driven development, emphasizing names and sentences that make the intent of code and tests discussable. Current Cucumber guidance describes the workflow as discovery, collaboration and examples: discuss a small upcoming change, agree on concrete cases, document them in a medium both humans and machines can read, and automate them where useful. The Given–When–Then (Gherkin) structure is an implementation pattern rather than the definition; BDD can be practiced without Cucumber or Gherkin, and Gherkin files produced without collaborative discovery do not constitute BDD. The characteristic chain is conversation about examples, agreed behavioral specification, implementation guidance, executable conformance feedback, and a living shared understanding.

Scope of Application

BDD applies within software delivery where teams must translate domain intent into observable system behavior. It is used for web applications, services, embedded systems, data products, and regulated software, but the exact automation interface varies. The systematic mapping literature characterizes BDD as semi-structured natural-language scenarios that can act both as requirements and executable test cases when connected to production code.

The method is particularly useful at boundaries: product-to-engineering, business-rule-to-code, service-to-service, and legacy-behavior-to-modernization. It is less useful for purely exploratory work whose expected outcome cannot yet be stated, and it should not force low-level algorithms or visual nuance into brittle prose scenarios.

Clarity

BDD replaces broad adjectives—“fast,” “secure,” “easy,” “handles refunds”—with examples that reveal decision boundaries. “Given an order shipped yesterday, when the customer requests cancellation, then…” forces participants to decide whether cancellation, return, or denial is intended. Another example can expose how the rule changes before shipment.

Manages Complexity

Software requirements are distributed across terminology, policy, tacit expectations, edge cases, and technical constraints. BDD compresses that distributed knowledge into a small portfolio of representative examples. Each example is concrete enough to discuss and automate, while the set collectively approximates a rule.

The examples also create traceability without requiring a separate translation at each handoff. The same scenario can anchor discovery, planning, coding, review, regression feedback, and documentation.

Abstract Reasoning

Example-to-rule induction. Compare cases to infer the intended business rule, then search for a nearby case that would distinguish competing formulations.

Rule-to-example deduction. Given an agreed rule, derive context-event-outcome examples at normal, boundary, and exceptional conditions.

Triangulation. Product clarifies value and policy, development exposes feasibility and architecture, and testing challenges observability and failure modes. Missing a perspective predicts a characteristic blind spot.

Knowledge Transfer

The full abstraction transfers among software products and architectures because the roles remain stable: stakeholders, examples, shared behavioral specification, implementation bridge, and feedback. The underlying collaboration and validation principles travel beyond software, but calling a policy workshop or manufacturing acceptance test “BDD” imports software-specific language without preserving the code-to-executable-specification loop.

The portable residue belongs to Shared Mental Model, Coordination, and Validation. BDD is the software-engineering package that couples them to observable system behavior.

Relationships to Other Abstractions

Current abstraction Behavior-Driven Development Domain-specific

Parents (2) — outgoing typed relations

• Behavior-Driven Development includes Shared Mental Model Prime

  shared_mental_model: scenarios provide a jointly inspectable account of expected system behavior.

• Behavior-Driven Development includes Validation Prime

  validation: executable examples compare the implemented system with intended outcomes.

Hierarchy paths (3) — routes to 3 parentless roots

• Behavior-Driven Development → includes Shared Mental Model → is a kind of Mental Model → is a kind of Representation → presupposes Abstraction

Show alternative paths (2)

Neighborhood in Abstraction Space

Behavior-Driven Development sits in a sparse region of the domain-specific corpus (89^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

• Cleanroom software engineering — 0.81
• Activity-centered design — 0.80
• Code Smell — 0.80
• Function-Behaviour-Structure ontology — 0.80
• Paper prototyping — 0.79

Computed from structural-signature embeddings · 2026-10-25