Scenarios

Writing clear, focused scenarios is the key to effective BDD testing.

Business Language

Write for Stakeholders

Scenarios should be readable by non-developers:

# Good: Business language
Scenario: Premium customer receives discount
  Given a premium customer exists
  When the customer purchases a product
  Then they should receive 20% discount

# Avoid: Technical implementation
Scenario: Test discount calculation
  Given user.subscription_tier = "premium"
  When POST /api/orders
  Then response.discount = 0.20

Use Domain Terminology

# Good: Uses business terms
Scenario: Farmer exceeds credit limit
  Given a farmer with 10 hectares of land
  When they apply for 50000 TL credit
  Then the application should be rejected

# Avoid: Generic terms
Scenario: User fails validation
  Given a user with attribute value 10
  When they submit form with value 50000
  Then it should return error

One Behavior Per Scenario

Focused Scenarios

Test one thing at a time:

# Good: Focused scenarios
Scenario: Add item to empty cart
  Given an empty cart
  When I add "Widget" to cart
  Then cart should contain "Widget"

Scenario: Cart shows correct total
  Given cart contains "Widget" priced at $50
  Then cart total should be $50

Avoid Kitchen Sink Scenarios

# Avoid: Testing too much
Scenario: Complete shopping flow
  Given I am logged in
  When I search for products
  And I add item to cart
  And I apply coupon
  And I checkout
  And I pay
  Then I should receive email
  And inventory should update
  And order should be created

Background Steps

Common Setup

Use Background for setup shared by all scenarios:

Feature: Order Management

  Background:
    Given I am logged in as admin
    And the system has products

  Scenario: Create order
    When I create a new order
    Then the order should be pending

  Scenario: Cancel order
    Given an existing order
    When I cancel the order
    Then the order should be cancelled

Keep Background Minimal

# Good: Minimal background
Background:
  Given a logged-in user

# Avoid: Too much in background
Background:
  Given a user "John" exists
  And the user has email "john@test.com"
  And the user has role "admin"
  And the user has verified email
  And the user has 10 orders
  And the system is in production mode

Scenario Outlines

Data-Driven Testing

Use outlines for variations of the same behavior:

Scenario Outline: Shipping cost calculation
  Given a package weighing <weight> kg
  When shipped to <zone>
  Then shipping cost should be $<cost>

  Examples:
    | weight | zone     | cost  |
    | 1      | domestic | 5.00  |
    | 1      | europe   | 15.00 |
    | 5      | domestic | 10.00 |
    | 5      | europe   | 35.00 |

Testing Boundaries

Scenario Outline: Password validation
  When I enter password "<password>"
  Then validation should <result>

  Examples: Length boundaries
    | password    | result |
    | 1234567     | fail   |  # 7 chars (min is 8)
    | 12345678    | pass   |  # 8 chars (exactly min)
    | 123456789   | pass   |  # 9 chars (above min)

  Examples: Character requirements
    | password    | result |
    | abcdefgh    | fail   |  # No numbers
    | 12345678    | fail   |  # No letters
    | abcd1234    | pass   |  # Mixed

Scenario Independence

Each Scenario Stands Alone

# Avoid: Dependent scenarios
Scenario: Create user
  When I create user "John"
  Then user should exist

Scenario: Edit user (depends on above!)
  When I edit user "John"  # Assumes John exists!
  Then changes should be saved

# Prefer: Independent
Scenario: Edit user
  Given a user "John" exists
  When I edit the user's name to "Jane"
  Then the user's name should be "Jane"

Why Independence Matters

• Scenarios can run in any order
• Parallel execution works correctly
• Failed scenarios don't cascade
• Easier to debug failures

Descriptive Names

Scenario Names

# Good: Describes the behavior
Scenario: Premium customer receives free shipping
Scenario: Order cancelled when payment fails
Scenario: Admin can view all user orders

# Avoid: Vague or technical
Scenario: Test case 1
Scenario: Happy path
Scenario: Verify POST endpoint

Use "should" for Outcomes

# Good: Clear expectations
Scenario: User should see error for invalid email
Scenario: Cart should update when item removed
Scenario: Payment should fail with expired card