Behavior Driven Development
Behaviour Driven Development (BDD) has a place in every stage of a project; it lets teams explore and understand a client’s business, to clearly identify their needs, describe what their project’s success looks like, and ensure that this vision is what is delivered. It lets teams build confidently and deliver software with real value back to the business.
What is BDD?
To explain the point of BDD, we have to start by accepting this simple premise: A large part of the challenges faced by software development projects are communication problems. Behaviour Driven Development is a way to:
- Structure communication to describe examples of how to use the software, these are called “scenarios”.
- Capture scenarios from the perspective of the stakeholders of the system.
- Learn and Use the language and terminology of the business.
- Gather just enough details of the system to be able to set a preliminary estimate.
- Leverage the scenarios as executable tests that drive the design of the software.
A set structure to document examples
BDD uses a simple structure to document examples of how a software app should behave. This structure uses 3 keywords, Given, When, and Then, to identify the 3 parts of a scenario:
_Given _some context, When some event or action happens, Then some outcome should be true as a response.
This simple set of words, Given, When, Then, forces a consistent focus on the app’s behaviour. They allow conversations to happen for each scenario that everyone can understand, whether they’re on the business or technical side of the project.
[note:Sample SENARIO{bg:orange}],[Senario: Successful withdrawal|Given Tom Have €100 in his account balance;When Tom requests €20 cash;Then €20 must be dispensed And his account balance must become €80{bg:green}]
From the perspective of Stakeholders
We start a project with a “Discovery Phase”. One of the work products of this phase is a list of features that the app will have. Those features then get broken into stories, and we write each story from the perspective of a Stakeholder of the system. Then, for each story, we work with the clients to discover examples of how that specific stakeholder uses the tool we’re building. Not only do we look for examples of success, but also examples of failure. And finally, we ask if there are examples of different ways to do the same thing. These scenarios are a list of actions that deliver value to this stakeholder.
[note:Feature: Cash withdrawal{bg:orange}],[Feature|Unique ID: 3.1.5.1;As: Account Holder;Provision: want; Action: withdraw cash from my account;Condition: sufficient Funds in my account balance;Objective: I can have some money for lunch{bg:blue}]->[Senario: Insufficient Funds{bg:green}],[Feature]->[Senario: Overdraft Coverage{bg:green}],[Feature]->[Senario: Successful withdrawal|Given Tom Have €100 in his account balance;When Tom requests €20 cash;Then €20 must be dispensed And his account balance must become €80{bg:green}]
Learn and use the business’ terminology
Ubiquitous language 1 is the term used by Eric Evans to describe the practice of building up a common language between developers and clients.
BDD’s focus on capturing examples in the language of the business, instead of in terms about software structure and user interface pieces, kickstarts the process of building a ubiquitous language right from the start.
A point that is sometimes understated around this common language, is that the developers are learning not only the words used by the business but what they mean when they interact with each other in different contexts of the software. This is a hard piece of learning to come by without a structured way of using concrete examples to uncover details about the business.
[note:Feature: Cash withdrawal{bg:orange}],[Feature|Unique ID: 3.1.5.1;As: Account Holder;Provision: want; Action: withdraw cash from my account;Condition: sufficient Funds in my account balance;Objective: I can have some money for lunch{bg:blue}]->[Senario: Insufficient Funds{bg:green}],[Feature]->[Senario: Overdraft Coverage{bg:green}],[Feature]->[Senario: Successful withdrawal|Given Tom Have €100 in his account balance;When Tom requests €20 cash;Then €20 must be dispensed And his account balance must become €80{bg:green}],[Business Domain Language|-account; -account balance; -account holder; -withdraw; -cash; -money; -dispensed; -funds; -insufficient funds; -overdraft coverage]
Enough detail to give an estimate
A User Story should include examples of successful use, failure situations and how to handle them, and maybe one or two alternate situations. This is a good starting point for the team to make a preliminary estimate on the story.
The number of scenarios in the story can also help flag ones that might be too big. We look for stories with a lot of alternate scenarios and split them into smaller, more manageable deliverables.
[note:Feature: Cash withdrawal{bg:orange}],[Feature|Unique ID: 3.1.5.1;As: Account Holder;Provision: want; Action: withdraw cash from my account;Condition: sufficient Funds in my account balance;Objective: I can have some money for lunch{bg:blue}]->[Senario: Insufficient Funds|Given Tom has €10 in his account balance;When he requests €20 cash; Then €0 must be dispended{bg:green}],[Feature]->[Senario: Overdraft Coverage{bg:green}],[Feature]->[Senario: Successful withdrawal|Given Tom Have €100 in his account balance;When Tom requests €20 cash;Then €20 must be dispensed And his account balance must become €80{bg:green}],[Business Domain Language|-account; -account balance; -account holder; -withdraw; -cash; -money; -dispensed; -funds; -insuficient funds; -overdraft coverage]
At the project estimation stage, we’re not looking to capture 100% of the scenarios for every story. There are diminishing returns on the effort, and it’s not reasonable to expect to lock down every aspect of a project’s scope and behaviour, before writing the first line of code.
A core principle of BDD is “enough is enough”. We’ll leave the details for a later blog post, but in this context it’s relevant on how far we go on identifying scenarios. We’re looking for just enough examples to give us just enough data to be able to estimate the project within reason.
Executable tests that drive the design of the software
BDD started out simply as a way to explain TDD (Test Driven Development) to new developers. They were having problems mapping their work back to real value to the business.
TDD is the practice of writing a failing test first, before adding any new functional code, and writing only enough code to make the failing test pass. The software gets built by repeating this process while making sure not to break any prior tests, and cleaning up the codebase and tests when needed. TDD creates many small unit tests that focus on confirming the technical implementation of the system, but it’s hard to keep both the technical quality and the business value in sight just with TDD.
The Given, When, Then format of our scenarios, aside from being descriptions of our system’s behaviour, is also a natural-language syntax called Gherkin used by an automated testing program called Cucumber 2.
Each line in the scenario translates into code: the Given lines become preconditions - what state the system must be in before we run the test, the When lines become the input into the system to trigger some behaviour, and the Then line specifies the expected response of the system, and what it should do or look like in response to the input. Each scenario is an executable test that gets run against the system. This is very cool !
Feature: Cash withdrawal
As Account Holder
I want to withdraw cash from my account if sufficient Funds in my account balance
So I can have some money for lunch
Senario: Successful withdrawal
Given Tom Has €100 in his account balance
When Tom requests €20 cash
Then €20 must be dispensed
And his account balance must become €80
Senario: Insufficient Funds
Given Tom has €10 in his account balance
When he requests €20 cash
Then €0 must be dispensed
Senario: Overdraft Coverage
Building the Right Thing
When we’re ready to start work on a story, we look through the scenarios we’ve already listed, and we check in with the client; together we remove any scenarios that may no longer apply, and we try to think of any we may have missed based on our latest understanding of the project.
[note:Feature: Cash withdrawal{bg:orange}],[Feature|Unique ID: 3.1.5.1;As: Account Holder;Provision: want; Action: withdraw cash from my account;Condition: sufficient Funds in my account balance;Objective: I can have some money for lunch{bg:blue}]->[Senario: Insufficient Funds|Given Tom has €10 in his account balance;When he requests €20 cash; Then €0 must be dispended{bg:green}],[Feature]->[Senario: Overdraft Coverage|Given Tom has €10 in his account balance;And he has €100 overdraft coverage;When Tom requests €20 cash;Then €20 must be dispensed;And his account balance must become -€10;And his overdraft allowance must become €90{bg:green}],[Feature]->[Senario: Successful withdrawal|Given Tom has €100 in his account balance;When Tom requests €20 cash;Then €20 must be dispensed And his account balance must become €80{bg:green}],[Business Domain Language|-account; -account balance; -account holder; -withdraw; -cash; -money; -dispensed; -funds; -insuficient funds; -overdraft coverage; -overdraft allowance]
Once we know we have our set of scenarios, we work through each one; run it as an executable test (that will start as failing), write the code to pass each step in the scenario, make the whole scenario pass, clean up the code as needed, and move on to the next scenario.
BDD is a Methodology
BDD starts right when the project starts. It helps in understanding client needs, it drives the structure of stories, it informs estimation, and drives the development of the system.
Developers and clients work together to agree on what the system will do by building concrete examples. BDD builds in a shared responsibility for the project scope, the system’s effectiveness, and the project’s success.
BDD focuses on the system’s effectiveness because every part of the code starts from examples that deliver business value. While TDD focuses on building the thing right, BDD’s focus is on building the right thing.
As a side-effect of this process, the team is also left with a safety net of tests around the project. Tests that allow them to make changes confidently.
1. “Ubiquitous Language”, Martin Fowler, https://martinfowler.com/bliki/UbiquitousLanguage.html ↩
2. “An open-source tool for executable specification”, Cucumber, https://cucumber.io ↩