Behavior-Driven Development

In Turkish: Davranış Odaklı Geliştirme

Updated September 30, 20262 min read

In short

Behavior-driven development is a practice where developers, testers, and business people agree on plain-language examples that become automated tests.

What is behavior-driven development?

Behavior-driven development, or BDD, is a collaborative way of building software in which the team agrees on how a feature should behave by writing concrete examples in plain language before the code is written. Those examples then become automated tests. Dan North introduced BDD in the mid-2000s as an evolution of test-driven development, shifting the focus from tests to behavior and to a shared vocabulary between business and technical people.

BDD starts with a conversation, often called a Three Amigos session, in which a product person, a developer, and a tester turn a user story into examples. The examples are written as scenarios in a Given-When-Then format, frequently in a structured language called Gherkin: Given a starting context, When an action happens, Then an expected outcome. A BDD tool connects each line to a small piece of code, called a step definition, so the scenarios run as automated acceptance tests and also serve as living documentation that stays up to date.

BDD is like agreeing on a photo of the finished cake and how it should taste before anyone starts baking, so everyone knows what success looks like. It fits business rules and user-facing features where a misunderstanding between business and development is expensive. It adds overhead, though: if nobody outside the development team ever reads the scenarios, ordinary tests may be simpler.

BDD is often confused with test-driven development. TDD is a developer's red, green, refactor loop at the level of individual units of code, while BDD works at the level of features and centers on conversations and shared language. The two combine well, with BDD scenarios describing a feature from the outside and TDD driving the code inside. Writing tests in Given-When-Then form is not BDD on its own; the collaboration is the core of the practice.

Key takeaways

BDD describes features as concrete examples that everyone on the team can read.
Scenarios follow the Given-When-Then pattern, often written in Gherkin.
Step definitions turn scenarios into automated acceptance tests.
It works at the feature level, while TDD works at the code level.
Collaboration, not the syntax, is what makes it BDD.

Example

Two BDD scenarios written in Gherkingherkin

Feature: Password reset

  Scenario: Registered user requests a reset link
    Given a registered user with the email "ada@example.com"
    When she requests a password reset for "ada@example.com"
    Then she receives an email with a reset link
    And the link expires after 30 minutes

  Scenario: Unknown email address
    Given no account exists for "nobody@example.com"
    When someone requests a password reset for "nobody@example.com"
    Then the page shows the same confirmation message
    And no email is sent

Readers ask

What is the difference between BDD and TDD?

TDD is a developer practice of writing a failing unit test before the code. BDD applies a similar test-first idea at the feature level, using plain-language scenarios that business people, developers, and testers write together.

What is Gherkin?

Gherkin is a simple structured language for writing BDD scenarios with keywords such as Feature, Scenario, Given, When, and Then. BDD tools read Gherkin files and run the matching step definitions as tests.

What does Given-When-Then mean?

Given describes the starting situation, When describes the action or event, and Then describes the expected outcome. The pattern keeps each scenario focused on one behavior.

Often compared

TDD vs BDDIn TDD, developers write a failing test before the code that makes it pass, while BDD builds on it with plain-language scenarios the whole team can read.