Behavior-driven development (BDD) describes software by what it does for the people who use it. Dan North (now Daniel Terhorst-North) set it out in his 2006 article “Introducing BDD”, and the idea fits in a sentence: the owner, the people who use the result and the webmasters agree on how the software should behave, in sentences all of them can read, and those sentences run as tests.
This module follows that idea from a user story to a running test, principles first:
Key principles of BDD: the user’s perspective, collaboration in a common language, behavior specified as scenarios, and checks that keep running on every change. Principles of BDD takes each in turn.
Given, When, Then
- Given: the starting context, the state of things before.
- When: the action or event that happens.
- Then: the outcome that should follow.
BDD in practice
- Discovery workshops: BDD often starts in a discovery workshop, where the owner and the people who use the result sit down with the webmasters and agree on examples of the behavior, before anyone writes code.
- Example mapping: Matt Wynne’s example mapping (2015) lays out a story on cards before any scenario is written: its rules, the examples that illustrate each rule, and the questions still open. Each rule can become a Gherkin Rule, and each example a scenario.
- Automated tests: Each scenario becomes an automated test that checks the software behaves as specified. On the Sean Dinwiddie’s Webmastery team, those tests drive the Redux Toolkit slices and RTK Query endpoints behind each feature that holds state. The lecture Redux Toolkit and Functional Programming tests a slice through its events, the way these scenarios do.
- Test-driven development (TDD): BDD and TDD often go hand in hand. In TDD, the test comes first: it defines the expected behavior before the code is written.
Benefits of BDD: software that does what its users need, a language the owner and the team share, a missing case caught while it is still a question, and scenarios that keep checking the software as it changes. Introduction to BDD sets out all four.
The hard parts
- Learning curve: BDD takes practice, and a team member new to it has a learning curve to climb. This module is the climb.
- Maintenance: A large suite of scenarios and tests takes upkeep, so it stays lean: a scenario that no longer names a behavior anyone needs is deleted.
- Tools and infrastructure: A Gherkin runner is one more tool to keep current. The team runs scenarios both ways and keeps exploring both: as executable steps with cucumber-js, or as tests named after each scenario in the codebase’s own runner, such as Vitest or Hspec, which adds no tool of its own.
BDD keeps development pointed at what users need and expect: people work it out together, agree in plain sentences, and let those scenarios guide both the building and the testing. The next module, on functional reactive programming (FRP), folds the events those scenarios name into state with pure reducers, and reads back what each Then checks through selectors.
Introduction to behavior-driven development (BDD), the next lesson, starts where the user stands.