Every software team has lived through this moment. A feature ships, the code works exactly as written, all the tests pass, and the product manager says, "That is not what we asked for." Nobody made a coding mistake. The mistake happened much earlier, when three people read the same requirement and imagined three different features.
That gap between what the business wants and what the code does is the problem behaviour driven development was created to solve. If you have been asking what is behaviour driven development, the short answer is this: it is a way of building software where the team agrees on how the system should behave, writes that behaviour down as concrete examples in plain language, and then uses those examples as automated tests.
This guide walks through the idea from the ground up, with examples, so you can decide whether it fits your team.
What is behaviour driven development?
Behaviour driven development (BDD) is an Agile practice that brings developers, testers, and business stakeholders together to describe software behaviour before it is built. Instead of starting from a technical specification, the team starts from real examples of how a user will interact with the feature.
Those examples are written in a structured but readable format, usually called Gherkin, and they serve three purposes at once:
- A shared requirement that everyone on the team can read and agree on.
- Acceptance criteria that define when a user story is actually done.
- An automated test that checks the finished code behaves as described.
For a deeper reference on the fundamentals, techniques, and tooling, Keploy maintains a detailed behaviour driven development glossary guide that covers the full concept in one place.
Where BDD came from
BDD grew out of an older practice. Dan North introduced the term in the mid-2000s while coaching teams on test driven development. He noticed that developers struggled with questions like "What should I test first?" and "What do I call this test?" The word "test" itself was part of the problem, because it pushed people to think about verification rather than intent.
North suggested shifting the language from tests to behaviour. Instead of writing a test called testLoginValid, you describe a behaviour: "a user with valid credentials should reach the dashboard." That small change in wording turned out to have a big effect. Once tests were written as sentences about behaviour, non-developers could read them, question them, and help write them.
How behaviour driven development works in practice
BDD follows a simple loop that repeats for every feature.
Step 1: Start with a user story
A user story captures who wants something, what they want, and why:
As a registered customer, I want to reset my password so that I can regain access to my account.
Step 2: Discuss concrete examples
The team then asks, "What does this look like in real situations?" A developer, a tester, and a product person (often called the "three amigos") talk through the happy path and the edge cases. What happens if the email is not registered? What if the reset link has expired?
Step 3: Write scenarios in Given-When-Then format
Each example becomes a scenario:
Feature: Password reset
Scenario: Registered user requests a reset link
Given a customer is registered with "asha@example.com"
When she requests a password reset for "asha@example.com"
Then she should receive a reset email within 2 minutes
Scenario: Reset link has expired
Given a customer has a reset link issued 25 hours ago
When she opens the reset link
Then she should see the message "This link has expired"
- Given sets up the starting context.
- When describes the action.
- Then states the expected outcome.
Step 4: Automate and build
Developers connect each line of the scenario to code (called step definitions) using a tool like Cucumber, Behave, or SpecFlow. The scenarios fail at first, because the feature does not exist yet. Developers then write the code until the scenarios pass.
Step 5: Keep scenarios as living documentation
Once the feature ships, the scenarios stay in the codebase. They run in the CI pipeline on every change, and they double as up-to-date documentation of how the system behaves.
Why teams adopt BDD
The main benefit of BDD is not the tooling. It is the conversation it forces before any code is written. Teams that adopt it usually report:
- Fewer misunderstood requirements, because ambiguity is caught while discussing examples, not after release.
- Better test coverage of real user journeys, since scenarios are written from the user's point of view.
- Documentation that stays accurate, because it fails loudly in CI the moment it goes out of date.
- Easier onboarding, since new team members can read feature files to learn what the system does.
BDD vs TDD at a glance
People often confuse the two, so here is a quick comparison.
| Aspect | Test driven development | Behaviour driven development |
|---|---|---|
| Main focus | Code correctness | System behaviour from the user's view |
| Who writes tests | Developers | Developers, testers, and business stakeholders |
| Test language | Programming language | Plain language (Gherkin) |
| Typical level | Unit tests | Acceptance and integration tests |
| Common tools | JUnit, pytest, NUnit | Cucumber, Behave, SpecFlow |
The two are not rivals. Many teams use TDD to build individual functions and BDD to confirm that the whole feature does what the business expects.
Common misconceptions about BDD
"BDD is just writing tests in Gherkin." Gherkin is a format, not the practice. A team that writes Gherkin alone at a desk, without talking to anyone, is doing test automation with extra steps.
"BDD replaces unit tests." It does not. BDD scenarios sit at a higher level. You still need unit and integration tests underneath them.
"Every test should be a BDD scenario." Scenarios work best for behaviour the business cares about. Low-level technical checks are usually clearer as regular unit tests.
When BDD is a good fit
BDD tends to pay off when:
- Requirements are complex or frequently misunderstood.
- Business stakeholders are willing to take part in example discussions.
- The product has many user-facing rules, such as pricing, permissions, or workflows.
It may be less useful for small internal tools, pure infrastructure work, or teams where no one outside engineering is available to collaborate.
FAQs
What is behaviour driven development in simple terms?
It is a way of building software where the team first agrees on examples of how a feature should behave, writes those examples in plain language, and then turns them into automated tests.
Is behaviour driven development only for testers?
No. BDD is a whole-team practice. Testers, developers, and business stakeholders all contribute to the scenarios.
What language is used to write BDD scenarios?
Most teams use Gherkin, which relies on keywords like Given, When, Then, And, and But.
Do I need a special tool to practise BDD?
You can hold BDD conversations without any tool, but automating scenarios requires a framework such as Cucumber, Behave, SpecFlow, or JBehave.
Conclusion
So, what is behaviour driven development? It is less about a testing framework and more about a habit: talk about behaviour first, capture it as examples, and let those examples guide the code. When a team gets that habit right, the "that is not what we asked for" moment becomes rare, and the test suite becomes something the whole team can actually read.
Top comments (0)