BDD Fundamentals: Behavior Driven Development, BDD vs TDD & Gherkin

What Is BDD (Behavior Driven Development)?

BDD (Behavior Driven Development) is a collaborative approach in which business people, developers and testers agree on how software should behave by discussing concrete examples — and then write those examples down in plain language so they become both the specification and the automated tests.

• Why it's used — so QA, developers and business share one clear understanding of a requirement before it's built, and so test scenarios are readable by non-technical stakeholders.
• How it's implemented — scenarios are written in Gherkin feature files using Given / When / Then; step definitions contain the automation logic, usually driving Selenium or an API client; tools such as Cucumber run them.

The result is business-readable requirements and automation-ready tests that stay in sync.

The Three Practices of BDD

BDD is often mistaken for "writing tests in Gherkin". It's really three practices, in this order:

1. Discovery — before development, the "three amigos" (business, development, testing) explore a story through examples and uncover rules, edge cases and open questions.
2. Formulation — the agreed examples are written as Gherkin scenarios that everyone can read and review.
3. Automation — the scenarios are connected to code with step definitions and run in CI, so they become living documentation that proves the behavior still works.

Teams that skip discovery and only automate usually get the cost of Gherkin without the benefit.

Example Mapping: A Quick Discovery Technique

In a 20–30 minute session, write the story at the top, then list its rules (business rules), examples under each rule, and questions nobody can answer yet. For "Apply a discount coupon":

• Rule: a coupon can be used once per customer → Example: Asha uses SAVE10 twice; the second attempt is rejected.
• Rule: expired coupons are rejected → Example: OLD2023 shows "This coupon has expired".
• Question: can a coupon be combined with a sale price? (Ask the product owner before building.)

Each example later becomes a scenario.

Why BDD Is Used in Automation Testing

BDD creates business-readable test scenarios and keeps automation aligned with real requirements.

"In my e-commerce project, manual test cases were unclear, so we implemented BDD using Cucumber. Feature files described scenarios in plain English, step definitions automated them with Selenium, and business users could review the feature files directly."

BDD vs TDD (and ATDD)

TDD means writing a failing unit test before the code (red → green → refactor). BDD grew out of TDD and moves the conversation to behavior in business language. ATDD is closely related to BDD, focusing on acceptance criteria agreed with the customer. They work well together: developers use TDD for the code while the team uses BDD for features.

"In our e-commerce project, developers used TDD with JUnit for module-level validation, and we used BDD with Cucumber for end-to-end feature validation."

More: BDD vs TDD.

Benefits of BDD in Real Projects

• Fewer misunderstandings — requirements are clarified with examples before coding.
• Tests aligned with business behavior — scenarios come straight from acceptance criteria.
• Living documentation — feature files always describe what the system currently does.
• Reusable automation — steps are shared across scenarios.
• Earlier defects — gaps are found in conversation, which is the cheapest place to find them.

Who Writes BDD Scenarios?

Ideally, they're written collaboratively by QA, developers and business analysts, and reviewed with the product owner as acceptance criteria before automation begins. In practice testers often draft them, but they should still be reviewed by the business — otherwise they're just test scripts in a different syntax.

What Is Gherkin?

Gherkin is a structured, human-readable language for writing BDD scenarios. Each line starts with a keyword such as Given, When or Then, and feature files use the .feature extension. Gherkin makes requirements clear and unambiguous, gives business and technical people a shared language, and links requirements directly to automation through step definitions that run in CI/CD.

Gherkin Keywords

Putting Them Together

Feature: Discount coupons

  Background:
    Given the customer has items worth 1000 in the cart

  Rule: A coupon can be used only once per customer

    Scenario: Coupon applied the first time
      When the customer applies coupon "SAVE10"
      Then the order total should be 900

    Scenario: Coupon rejected the second time
      Given the customer has already used coupon "SAVE10"
      When the customer applies coupon "SAVE10"
      Then the message "Coupon already used" should be shown

Full details on Scenario Outline, Examples and Data Tables: Feature Files Explained.

Good vs Bad Scenarios

The most common mistake is writing imperative scenarios that describe clicks instead of behavior:

# ❌ Imperative — breaks whenever the UI changes, hard for business to read
Scenario: Login
  Given I open "https://shop.example.com/login"
  When I type "asha@example.com" into the "email" field
  And I type "Secret@123" into the "password" field
  And I click the blue "Sign in" button
  Then I should see the element "#dashboard"

# ✅ Declarative — describes what, not how
Scenario: Registered customer logs in
  Given Asha is a registered customer
  When she logs in with valid credentials
  Then she should see her dashboard

Keep scenarios short (roughly 3–7 steps), one behavior each, in business language — the "how" belongs in step definitions and page objects.

Common BDD Myths

• "BDD means using Cucumber." Cucumber is a tool; BDD is the collaboration. You can practice BDD without automating anything.
• "BDD replaces unit tests." No — unit tests (often written with TDD) still check the code; BDD scenarios check behavior.
• "Every test should be a Gherkin scenario." No — technical and low-level checks are simpler as normal code-based tests.

More real-world pitfalls: BDD Challenges in Real Projects.

📚 Official documentation: Cucumber documentation

FAQs

What Is BDD in Simple Terms?

A way for business, developers and testers to agree on how software should behave using concrete examples written in plain language — which then become automated tests.

What Is the Difference Between BDD and TDD?

TDD is developer-focused: write a failing unit test, then the code. BDD is team-focused: describe behavior with business examples in Gherkin, used across QA, development and business.

What Are the Three Practices of BDD?

Discovery (exploring examples together), formulation (writing them as scenarios) and automation (connecting scenarios to code).

Who Writes BDD Scenarios?

Ideally QA, developers and business analysts together, reviewed with the product owner as acceptance criteria.

What Is Gherkin?

A structured, human-readable language for BDD scenarios using keywords like Feature, Scenario, Given, When and Then.

What Are the Main Gherkin Keywords?

Feature, Rule, Background, Scenario, Scenario Outline, Examples, Given, When, Then, And and But.

Is Cucumber the Same as BDD?

No. Cucumber is a tool that runs Gherkin scenarios; BDD is the collaborative practice behind them.

Next Steps

• The Complete Cucumber BDD Tutorial — from feature files to a framework
• Step Definitions & Cucumber Expressions
• Cucumber & Gherkin Cheat Sheet
• Top 15 BDD & Cucumber Interview Questions · Cucumber BDD Visualizer