Behaviour-driven development in plain English

Your developers have started saying "BDD" in meetings. Perhaps it came up in a proposal, or a supplier mentioned it while describing how they test. You nodded, and now you would like to know what it is before you agree to pay for it.

It's a fair question, and the answer is less technical than the name suggests. Behaviour-driven development, or BDD, is a way of agreeing in plain sentences what the software should do before anyone builds or changes it, and then keeping those sentences as tests that prove it still does. This article explains the idea, shows one small example, and lists what to ask a supplier.

The problem it solves

Most disappointing software starts with a sentence that two people read differently.

"Invoices over a certain value need approval." The finance director hears one thing. The developer builds another. Nobody notices until the first invoice goes through that should have been stopped, or the first one is stopped that shouldn't have been. By then the software is built and the conversation is about who misunderstood whom.

BDD moves that conversation to the start. Before building, the people who know the business and the people who build the software sit down and work through concrete examples until they agree. That way the misunderstanding turns up while it still costs a conversation.

Given, When, Then

The examples are written in a simple, fixed shape. Each one says what the situation is (Given), what happens (When) and what should result (Then).

Here is an invented, generic example for an invoice approval rule:

Feature: Invoice approval

  Scenario: A large invoice needs a second approver
    Given the approval limit for one person is £5,000
    And an invoice for £12,000 has been entered
    When the first approver approves it
    Then the invoice is still waiting for a second approver

  Scenario: A small invoice needs only one approver
    Given the approval limit for one person is £5,000
    And an invoice for £800 has been entered
    When the first approver approves it
    Then the invoice is ready for payment

You can read that without any technical background, and that's the point. If the finance director reads the first scenario and says "actually, over £10,000 it should go to the finance director, not another approver", the specification has just caught a misunderstanding for the price of a sentence.

The notation has a name, Gherkin, and it's used by a family of tools that began with Cucumber. There are versions for most programming languages. You don't need to learn the syntax; you need to be able to read the result.

Examples as a shared language

Over time the scenarios build up into a shared vocabulary. "Approver", "ready for payment" and "waiting for a second approver" mean the same thing to the business and to the engineers, because they were agreed together and written down. The Cucumber project describes BDD as working in three steps: discovery (structured conversations using real examples), formulation (writing those examples in a form that people and computers can both read) and automation (connecting each example to the software so it can be checked).

The third step is what separates BDD from a requirements document. A requirements document is correct on the day it's written and drifts from then on. A scenario that is connected to the software is run every time the software is changed. If someone alters the approval rule and breaks the agreed behaviour, the scenario fails and the change doesn't go out.

That's what people mean by living documentation: a description of what the system does that stays in step with the system, because it's run. For anyone who has inherited software with a ten-year-old specification nobody trusts, that is a real advantage.

How it relates to test-driven development

You may also hear "TDD", test-driven development. It's a different tool for a different reader, and both are worth having.

• TDD is mainly for developers. They write small unit tests that check how individual pieces of code work, writing each test before the code it checks, and use them to design the code and catch mistakes quickly. (Unit tests can be written without TDD too; TDD is the habit of writing them first.) A good suite of these is fast, precise and essential for safe changes.
• BDD sits on top. It agrees the behaviour with the business first, in words the business can read, and checks the system as a whole against those agreements.

A team can do either on its own, but the combination is the strongest: unit tests that keep the code sound, and behaviour scenarios that keep it doing what the organisation actually asked for. Our own method for software care is specification first, then automated tests, independent review and human sign-off, and written behaviour scenarios are a natural way to hold that specification.

Why it matters if someone else will take over

This is where a business reader gains most. When software changes hands, the hardest thing to recover is intent: why does it do that, and is that deliberate? The code can tell you what happens. It rarely tells you whether it was meant to.

A set of readable scenarios is a record of intent. A new engineer can read what the system is supposed to do, run the scenarios, and see which of them pass today. If you are thinking about adding tests to code nobody dares change, behaviour scenarios are a natural next step once the safety net is in place. They also help an auditor, insurer or customer who asks how you know the software does what you say it does. "Here are the agreed examples, and here is the latest run" is a good answer.

What BDD does not do

It is not free, and it doesn't suit every piece of software.

• Writing good scenarios takes time and a few people in a room. That time is the point, but it is a cost.
• Scenarios are best for business rules and outcomes. They're a poor fit for how a screen looks, or for the speed of a report.
• Badly written scenarios become a burden: long, repetitive, full of clicks and field names that nobody wants to read. Good ones stay short and talk about business outcomes.
• A scenario nobody reads is just another test. The value comes from the conversation and from people actually using the result.

A sensible first step

You don't need to commit to anything to find out whether this suits you. Three small things to try:

1. Ask your supplier or developer: "Do you write behaviour specifications for the rules that matter most to us, and can I read them?"
2. Pick one business rule that has caused an argument, such as an approval limit, a discount, a renewal date or a cut-off time, and ask for it to be written as three or four Given, When, Then examples. Read them aloud with the people who own the rule.
3. If the answer to the first question is no, ask what they use instead to prove the software still does what was agreed.

If you'd like to know where your own system stands, including whether its important rules are written down anywhere, a software health audit is a good place to start, and our software care page explains how we look after systems once they're in good order.