What is Behaviour 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

Let’s unpack each of these points.

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.

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.

Learn and use the business’ terminology

Ubiquitous language 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.

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.

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.

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!

Note: We’re using Cucumber specifically because of its tight use of the Given/When/Then structure, and Gherkin as a natural-language syntax. Scenarios read as plain english which is easier for non-developers to work with. While Javascript testing frameworks like Mocha, and Jasmine also call themselves BDD frameworks, they are better suited as unit testing tools. Future posts will dig into the differences between types of testing and the best tools for each one.

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.

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.

Repeat for each scenario in the story until the story is done. Repeat for each story in the project until the project is done.

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.

Thanks for reading! Now that we’ve established the WHAT of BDD (at least what it is to OK GROW!), the next post in this series will dig into the HOW of BDD.

Originally published at www.okgrow.com.