What BDD Actually Is (and Isn't)

What BDD Actually Is (and Isn't)

Behaviour-Driven Development (BDD) is one of the most misunderstood practices in the agile testing toolkit. Teams often think they are doing BDD because they write Gherkin scenarios. That is a narrow view — BDD is a collaboration practice first, and an automation technique second.

The Original Purpose of BDD

Dan North introduced BDD in 2006 as an evolution of TDD, motivated by a specific problem: developers writing unit tests that tested implementation details rather than behaviour, and teams having no shared language between business and technical stakeholders.

BDD introduced the Given/When/Then structure not primarily as a test format, but as a communication framework that forces teams to specify behaviour in terms that everyone — developer, tester, business analyst — can understand and agree on.

What BDD Is

1. A collaboration practice: The "Three Amigos" (Dev, QA, BA) meet to discuss a feature before anyone writes code. The conversation surfaces ambiguities, edge cases, and competing assumptions.

2. A shared language: Gherkin scenarios are the written output of the Three Amigos conversation — a shared specification that is both human-readable and automatable.

3. Living documentation: When Gherkin scenarios are automated with Cucumber, they become executable specifications. If the scenario passes, the feature works as specified. If it fails, the specification or implementation is wrong.

What BDD Is Not

• Not just writing Gherkin: Teams that write Gherkin in isolation (without the conversation) get the syntax without the benefit. The scenario becomes a test — not a shared understanding.

• Not a testing tool: Cucumber is a tool. BDD is a practice. You can do BDD without Cucumber, and you can use Cucumber without doing BDD.

• Not always the right approach: BDD adds overhead. For internal APIs, complex algorithms, or highly technical features, the business language of Gherkin may not add value over plain unit tests.

The Benefit That Matters

When BDD works, the scenario file serves as a contract. Before the sprint ends, the product owner can read the Gherkin file and verify — without technical knowledge — whether the feature was built as agreed. That is valuable.