BDD Patterns

Master Behavior-Driven Development patterns to write clear, business-readable specifications that drive implementation.

Given-When-Then Structure

The fundamental BDD pattern uses three parts:

Given: The initial context or preconditions When: The action or event being tested Then: The expected outcome or result Feature: User Authentication

Scenario: Successful login with valid credentials Given a registered user with email "user@example.com" And the user has password "secure123" When the user submits the login form with correct credentials Then the user should be redirected to the dashboard And a session should be created

Feature File Organization Feature: Shopping Cart As a customer I want to manage items in my cart So that I can purchase products I'm interested in

Background: Given I am logged in as a customer And the product catalog is available

Scenario: Add item to empty cart Given my cart is empty When I add "Blue T-Shirt" to my cart Then my cart should contain 1 item And the cart total should be $29.99

Scenario: Remove item from cart Given my cart contains "Blue T-Shirt" When I remove "Blue T-Shirt" from my cart Then my cart should be empty

Scenario Outlines for Data-Driven Tests Scenario Outline: Password validation Given I am on the registration page When I enter password "" Then I should see ""

Examples: | password | message | | abc | Password too short | | abcdefgh | Password needs a number | | abcdefgh1 | Password accepted | | abcdefgh1! | Password accepted |

Step Definition Patterns

Ruby/Cucumber example

Given('a registered user with email {string}') do |email| @user = User.create!(email: email, password: 'password123') end

When('the user submits the login form with correct credentials') do visit login_path fill_in 'Email', with: @user.email fill_in 'Password', with: 'password123' click_button 'Log In' end

Then('the user should be redirected to the dashboard') do expect(page).to have_current_path(dashboard_path) end

When to Use This Skill

Use bdd-patterns when you need to:

Write acceptance tests that stakeholders can understand Define behavior before implementation Create living documentation from tests Bridge communication between developers and business Ensure features meet business requirements Best Practices Write scenarios from the user's perspective Keep scenarios focused on single behaviors Use declarative language, not implementation details Reuse step definitions across scenarios Use Background for common setup steps Keep feature files organized by domain area Common Pitfalls Writing scenarios that are too technical Coupling steps to specific UI implementations Creating overly complex scenario outlines Not maintaining feature files as code changes Mixing multiple behaviors in one scenario