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.