Behavior-driven development turns a user story’s acceptance criteria into scenarios in plain language, and each scenario becomes a test the software must pass.
What BDD is
Behavior-driven development is an agile practice that puts developers, testers and the business around one table, talking about one thing: what the software should do, seen from the user’s side. Dan North (now Daniel Terhorst-North) developed it from 2003 and set it out in 2006, in “Introducing BDD”, starting from tests named as sentences about behavior.
Each behavior is written as a scenario in plain language, usually in Given-When-Then form, in the language called Gherkin. Here is one:
Feature: Cart
Scenario: Adding a product to the cart
Given "Widget A" is in stock at $25
And the cart is empty
When the customer adds "Widget A" to the cart
Then the cart contains "Widget A"
And the cart total is $25Five steps, and two readers with different questions. The owner reads them and says whether that is what they asked for; a test checks them and says whether the software does it. That gives the owner and the webmasters one set of sentences to agree on before the software is built.
Why it matters
- User-centric: BDD has you think from the user’s perspective and ties every feature to a need someone named, so the owner can check the software against it.
- Improved communication: A plain-language scenario is the one document the developer, the tester and the owner all read the same way.
- Clear documentation: The scenarios double as documentation of what the software does, written so the next person can read it, and the test that checks each one carries its name.
- Early detection of issues: A misunderstanding found while the scenario is still words costs a conversation; found after the code is written, it costs rework.
In the team’s work
On the Sean Dinwiddie’s Webmastery team, every custom feature is written as Gherkin scenarios before it is built. BDD helps you:
- Say what your software should do, from the user’s side, before it is built.
- Give your team one set of sentences to work from.
- Keep a plain record of what your software does.
- Check your software against the needs and expectations of your users, on every change.
BDD is less a tool than a habit: the behavior is agreed in plain words before any code is written, and the work is done when those words pass as tests. Module 2 teaches the habit.
Next steps
The next lesson introduces functional reactive programming (FRP), the functional ideas behind the application state those scenarios test. The lecture What Is a Function? starts those ideas at the pure function, the easiest code to test.