BDD Principles

Master the foundational principles and philosophy of Behavior-Driven Development.

What is BDD?

Behavior-Driven Development (BDD) is a collaborative software development approach that:

Bridges the gap between business and technical teams

Uses concrete examples to describe system behavior

Creates living documentation that serves as tests

Focuses on delivering business value

Promotes shared understanding through conversation

Core Philosophy

Discovery > Development > Delivery

Discovery

Collaborate to understand requirements

Hold Three Amigos sessions

Explore with examples

Challenge assumptions

Build shared understanding

Development

Implement guided by examples

Use examples as specifications

Automate examples as tests

Follow outside-in TDD

Delivery

Validate against real behavior

Executable specifications provide confidence

Living documentation stays current

Regressions are caught early

The Three Amigos

A practice where three perspectives collaborate to explore and define features:

1. Business Perspective (Product Owner/BA)

What problem are we solving?

What value does it provide?

What are the business rules?

2. Development Perspective (Developer)

How might we build this?

What are the technical constraints?

What are the edge cases?

3. Testing Perspective (Tester/QA)

What could go wrong?

What are we missing?

How will we verify this works?

Example Three Amigos Session

Feature

Password Reset

Business

"Users who forget their password need a way to reset it via email."

Developer

"We'll need to generate secure tokens with expiration. How long should tokens be valid?"

Tester

"What happens if they request multiple reset emails? Can old tokens still be used?"

Business

"Tokens should be valid for 1 hour. Multiple requests should invalidate old tokens."

Developer

"Should we rate-limit reset requests to prevent abuse?"

Tester

"What if the email address doesn't exist in our system?"

Business

"For security, show the same success message whether or not the email exists."

Outcome

Concrete examples that become scenarios:

Scenario:

Request password reset with valid email

Given

a

user account exists for

"user@example.com"

When

I

request a password reset for

"user@example.com"

Then

I

should receive a reset email

And

the reset link should be valid for 1 hour

Scenario:

Request password reset with non-existent email

When

I

request a password reset for

"nonexistent@example.com"

Then

I

should see a success message

But

no email should be sent

Scenario:

Multiple password reset requests

Given

I

have requested a password reset

When

I

request another password reset

Then

the previous reset link should be invalidated

And

I

should receive a new reset email

Living Documentation

BDD scenarios serve as:

Executable Specifications

Automated tests that verify behavior

Documentation

Up-to-date description of how the system works

Common Language

Shared vocabulary between business and technical teams

Regression Suite

Safety net when making changes Example: Living Documentation Feature: Promotional Discount Application To attract customers and increase sales As a marketing manager I want to offer promotional discounts Rule: Percentage discounts apply to order subtotal Example: 20% off for orders over $100 Given I have a $150 order When I apply a "20% off" promotion Then my discount should be $30 And my order total should be $120 Rule: Minimum purchase amount must be met Example: Promotion requires $50 minimum Given I have a $40 order When I try to apply a "$50 minimum" promotion Then the promotion should not apply And I should see "Minimum purchase not met" Rule: Only one promotion per order Example: Cannot stack multiple promotions Given I have a $100 order And I have applied "10% off" When I try to apply "Free shipping" Then I should see "One promotion per order" And only "10% off" should be applied Ubiquitous Language Develop and use a shared vocabulary: ❌ Technical Jargon : "When the user submits the form, we validate the input, hash the password with bcrypt, insert a record into the users table, and return a 201 response." ✅ Ubiquitous Language : "When a customer registers, we verify their information, create their account, and send a welcome email." Building Ubiquitous Language Discover terms through conversation: What do you call this? What's the difference between X and Y? When does this state change? Document terms in scenarios:

Use "Member" not "User" (business term)

Given I am a Gold Member

Use "Place order" not "Submit order" (domain term)

When I place an order

Use "Pending" not "In progress" (system state)

Then the order should be Pending

Keep a glossary:

Member: A customer with a subscription

Guest: A customer without a subscription

Order: A collection of items ready for purchase

Cart: A temporary collection of items being considered

Example Mapping

A workshop technique to explore features with examples:

The Four Colors

Yellow Cards

User Stories/Features

Blue Cards

Rules (acceptance criteria)

Green Cards

Examples (scenarios)

Red Cards

Questions (uncertainties)

Example Mapping Session

Story

User registration

Rules

(Blue):

Email must be unique

Password must be strong

Age must be 18+

Examples

(Green):

Register with valid details → Success

Register with existing email → Error

Register with weak password → Error

Register under 18 → Error

Questions

(Red):

Do we verify email addresses?

What defines a "strong" password?

Do we need parent consent for minors?

Specification by Example

Use concrete examples to drive development:

Vague Requirement

"Users should be able to search for products."

Specification by Example

Scenario:

Search by product name

Given

products

"Laptop"

,

"Mouse"

,

"Keyboard"

exist

When

I

search for

"lap"

Then

I

should see

"Laptop"

in results

But

I

should not see

"Mouse"

or

"Keyboard"

Scenario:

Search with no results

Given

products

"Laptop"

,

"Mouse"

exist

When

I

search for

"phone"

Then

I

should see

"No results found"

Scenario:

Search is case-insensitive

Given

a

product

"Laptop"

exists

When

I

search for

"LAPTOP"

Then

I

should see

"Laptop"

in results

Outside-In Development

Start from the outside (user-facing behavior) and work inward:

Write a failing scenario

(acceptance test)

Write a failing unit test

(for the layer you're working on)

Write minimum code

to make unit test pass

Refactor

Repeat

until scenario passes

Scenario (Acceptance) ─┐

├─> Controller Test ─┐

│ ├─> Service Test ─┐

│ │ ├─> Code

│ │ │

│ ├─ Service │

│ │ │

├─ Controller │ │

│ │ │

Scenario Passes ───────┴────────────────────┴─────────────────┘

BDD vs TDD

TDD

(Test-Driven Development):

Developer-focused

Tests implementation

Red-Green-Refactor cycle

Unit tests guide design

BDD

(Behavior-Driven Development):

Business-focused

Tests behavior

Conversation-Specification-Automation

Scenarios guide development

They complement each other:

BDD: What should we build? (outside-in)

TDD: How should we build it? (inside-out)

Key Principles

Collaboration is essential

- BDD requires active participation from business, development, and testing

Examples clarify requirements

- Concrete examples reveal ambiguities and edge cases

Automate what matters

- Not everything needs to be automated, focus on high-value scenarios

Think behaviors, not tests

- Describe what the system does, not how it's tested

Iterate and refine

- Scenarios evolve as understanding deepens

Keep scenarios maintainable

- Write clear, focused scenarios that are easy to update

Common Misconceptions

❌ "BDD is just testing with Cucumber"

✅ BDD is a collaborative practice; tools are just enablers

❌ "BDD means writing tests before code"

✅ BDD means discovering requirements through examples before implementation

❌ "BDD scenarios should test everything"

✅ BDD scenarios should document key behaviors; use unit tests for details

❌ "Only testers write scenarios"

✅ Business, developers, and testers collaborate on scenarios

❌ "BDD slows down development"

✅ BDD reduces rework by building the right thing the first time

Benefits of BDD

Reduced rework

Build the right thing from the start

Better collaboration

Shared understanding across roles

Living documentation

Always up-to-date specifications

Faster onboarding

New team members learn from scenarios

Regression safety

Automated scenarios catch breaking changes

Business confidence

Stakeholders see value being delivered Remember: BDD is fundamentally about communication and collaboration. The goal is to build software that delivers real value by ensuring everyone has a shared understanding of what needs to be built.