Behaviour Driven Development
Behaviour Driven Development (BDD) specifies the behaviour expected of a solution through examples, written in a fixed grammar: given a starting situation, when a particular event occurs, then a particular outcome is observed. The business supplies the examples and the team puts them into shape. The same text then does three things: it documents the intended behaviour, it is the acceptance criterion for the backlog item and a tool runs it as an automated test. The practice comes from Dan North, who swapped the vocabulary of testing for the vocabulary of behaviour to remove the translation between what the business wants and what the team builds and then verifies. The Agile Extension to the BABOK Guide files it under requirements management, in the service of a delivery team.
Goal
Behaviour Driven Development is a practice of specification by example. You write the real cases the solution will have to handle, each as a three-part scenario: the state of things before, the triggering event, the observable outcome after. The scenario is text, readable by someone from the business who has never opened a development tool and structured enough for a test runner to execute it as it stands.
The problem it addresses is information lost in translation. A need voiced by the business is restated as a requirement by the analyst, then as a design by the developer, then as a test case by the tester. Each restatement is an opportunity to read it wrong, and the gap shows up at acceptance testing, when correction costs the most. BDD removes the relays by holding all four points of view in a single text, dictated by the business and executed by the tooling. Dan North calls this shared language the first gain of the practice, ahead of any automation.
The deliverable is a set of scenarios attached to a backlog item, extended as the team finds the cases the first pass left out. The Agile Extension sums the intent up in three effects: more value, less waste and more direct communication between the stakeholders and the delivery team, obtained by focusing the analysis on the behaviour the customer expects. The terms behaviour driven development, acceptance test driven development and specification by example are commonly used for one another, without the guide drawing the boundary between them.
Usage
When to use it
- Iterative delivery: fixing the expected behaviour item by item, just before it is built.
- Business and team with no shared vocabulary: where the gap between what was expected and what was delivered keeps recurring, a concrete example closes the interpretation a general statement leaves open.
- Acceptance tests to automate: written once, the scenario reads back as a specification and runs as a test.
- Traceability to demonstrate to an auditor or a regulator: the executed suite attests which behaviour is verified and when it was.
- A design to pin down: running the grammar over a solution already sketched keeps the discussion on a definite behaviour.
When not to use it
- Combinatorial business rules: the number of scenarios explodes and stops being traceable, use a decision table.
- Quantified non-functional requirements: a behaviour carries neither response time nor volume, write measured acceptance criteria.
Description
The practice grew out of test driven development. In 2003 Dan North built a test framework, JBehave, that replaced "test" with "behaviour", because the teams he was coaching kept stumbling on the same questions: what has to be tested, how far and at what point. With Chris Matts he formulated the "given, when, then" template in 2004, for requirements analysis. The 2006 article that fixes the practice is therefore about language first: the claimed gain is a vocabulary shared by analysts, testers, developers and the business.
The three elements
The examples are situations that actually happened, brought by the stakeholders. The product owner supplies them and, in doing so, clarifies their own thinking: a particular case they took to be obvious turns out to be arguable as soon as the outcome has to be written down. The business analyst facilitates that discovery and answers for the completeness of the example set, which nobody else watches. Not every example falls inside the scope of the current increment.
The grammar, called Gherkin, is the mould the example has to fit. The template the Agile Extension retains is deliberately spare, four keywords, which makes it readable without any training and parsable by a machine. Gherkin has a few more, among them the Scenario Outline and its Examples table, which factors out the variants that differ only in their data. That spareness is also an analytical constraint: an example that will not go into the mould is the sign of a need still vague or of a scenario that contains two.
Execution closes the loop: several products read scenarios in this format and bind them to test code. The specification then becomes a test that fails as soon as the behaviour changes, the only mechanism that signals of its own accord that a piece of documentation has stopped being true. Without that step the technique stays useful for the conversation and the suite of scenarios ages like any other document.
The grammar, keyword by keyword
A scenario carries a title that names the case it handles, then lines introduced by the template's four keywords. The rule that shapes everything else is the single trigger: one WHEN per scenario. Two events in one scenario mean two scenarios, and the author who merges them no longer knows which of the two failed. Starting conditions and expected outcomes, on the other hand, combine freely with ANDs.
| Keyword | What it sets | Match in the test |
|---|---|---|
| Given | The state of things before the event: the data in place, the account, the entitlement, the stock. Nothing moves yet. | Setup |
| When | The triggering event, one per scenario. This is the act whose effect is under examination. | Execute |
| Then | The observable outcome, worded so that a third party can establish whether it is reached. | Assert |
| And | Extends the keyword before it: one more starting condition or one more expected outcome. | Attaches to the preceding block |
The Three Amigos session and the "what if" questions
The usual session brings three roles together, hence its name of Three Amigos: the product owner, who brings the case and rules on what the solution has to do; the tester, who looks for the cases nobody has considered; the developer, who questions the trigger and the data the scenario assumes to be in place. Each looks at the same example from an angle the other two do not have, and the disagreement surfaces at the moment when it is settled in one sentence.
The business analyst's work in that session has a name in the guide: asking the "what if" and "what about" questions that bring the missing scenarios to light. Each question bears on a variation of one GIVEN line. What if the balance were not enough? What if the payee were not yet registered? What if the transaction fell on a cantonal public holiday? Each answer is either one more scenario or a business rule nobody had written down. This is where the technique pays best. These questions are also the first to go when the session is cut short.
Running the technique
- Pick the backlog item and gather the three roles
A session covers one backlog item. Without the product owner the session produces assumptions; without the tester it produces only the happy path. - Have the business tell the examples
Ask for cases that happened, with their real values. A file handled last week is worth more than a generality. - Ask the "what if" questions
Every variation of a starting condition is a candidate scenario. Answers that fall outside the increment's scope are noted too, without being put into shape. - Put it into shape
A title that names the case, one WHEN, the conditions and the outcomes combined with ANDs. The values appear in the text, spelled out. - Check the coverage
The set contains at a minimum the nominal case, the rejection cases and the boundary cases where a rule flips. A scenario whose outcome does not follow from the conditions stated is incomplete. - Attach the scenarios to the backlog item
They become its acceptance criteria and the basis for the end-of-iteration demo. - Automate and replay
Each scenario is bound to test code and replayed at every integration. A scenario that is never run is no more than a comment. - Prune
At every rule change the scenarios concerned are rewritten or deleted. A suite left to grow becomes unreadable before it becomes wrong.
Where the scenario sits among the acceptance criteria
A given, when, then scenario is one format of acceptance criterion among others. Acceptance and evaluation criteria address the general question: under what conditions is a solution accepted and on what scales are several candidates compared. BDD is the collaborative practice that produces one of those formats, the one the business can read and a tool can run. A project writes its availability, cost or compliance criteria in other forms and uses the scenario where what is being judged is a behaviour.
What makes the technique fail
The scenario written in the vocabulary of the screen
"When I click the Confirm button on the Payments tab" describes an interface where the scenario has to describe a behaviour. The scenario breaks at the first redesign of the interface although the business rule has not moved, and the business stops rereading it because it no longer recognises its own affairs in it. Write the act, "when I confirm the transfer", and leave it to the technical layer to know where the button is.
The missing scenario
This is the limitation the guide names first: with nobody to ask the "what if" questions, cases fall through. The suite passes in full while being incomplete, which is more dangerous than having no tests at all, because it reassures.
The suite that runs away
When the business rules are combinatorial, the scenarios multiply faster than anyone can follow them, up to a suite whose contents nobody knows any more and that nobody dares touch. Variants of values belong in a Scenario Outline and its table. Combinations of rules are handled in a decision table, and BDD keeps the few scenarios that illustrate the overall behaviour.
The scenario written after the code
The scenario then describes the behaviour the code already produces. It always passes and it gives the project the illusion of coverage.
Gherkin without the conversation
A team that writes its scenarios on its own ends up with well-formed files and with the defect the technique exists to remove: a specification written without the business. The grammar is worth only the session that fills it.
AI considerations
On this technique a language model does four useful things. It generates a list of "what if" questions from a backlog item and its business rules, against which the session can measure itself. It puts text into shape: give it the minutes or the transcript of the session and it draws structured scenarios out of them, which the session corrects. It finds duplicates and overlaps in a suite that has grown too big to reread. It aligns the three languages for a team working in French, German and English, the grammar being spare enough to survive translation.
The limits follow from what an example is. The example belongs to the business: it is a case that occurred in this organisation, with its own amounts, its own thresholds and its own in-house exceptions. A model ordered to produce some will manufacture a transfer limit, a revocation period or a CHF amount that look right and match no rule of the house. The false scenario will be automated as faithfully as a true one. A generated scenario nobody discusses reproduces the defect of Gherkin without the conversation. Thresholds that commit money or compliance are checked against the written rule. Real examples also carry personal data, customer names, AHV numbers, IBANs, amounts: they are anonymised before anything goes to a public model.
Examples
A Swiss retail bank is adding a daily transfer limit to its e-banking. The session produces two scenarios: the one that goes through and the one the limit stops.
| Scenario 1: transfer within the daily limit | |
|---|---|
| Given | an available balance of CHF 4'200 on my current account |
| And | a daily transfer limit of CHF 5'000 still untouched |
| When | I confirm a transfer of CHF 1'200 to a registered payee |
| Then | the transfer is executed the same day |
| And | the available balance drops to CHF 3'000 |
| And | the remaining daily limit drops to CHF 3'800 |
| Scenario 2: daily limit already used | |
| Given | an available balance of CHF 4'200 on my current account |
| And | a daily transfer limit of CHF 5'000 of which CHF 4'000 is already used |
| When | I confirm a transfer of CHF 1'200 to a registered payee |
| Then | the transfer is refused |
| And | the available balance stays at CHF 4'200 |
| And | the message states the amount still available on the limit, CHF 1'000 |
This is the usual shape of a useful set of scenarios: variants held tight around one condition that flips. The reader recovers the outcome by arithmetic, CHF 5'000 of limit less CHF 4'000 already used leaves CHF 1'000, which refuses a transfer of CHF 1'200. Writing a single scenario would have forced the flip to be stated as a general rule, that is, to leave the example for the abstraction the technique sets out to avoid.
The session produced more than those two texts. The third case raised, "what if the transfer were in a foreign currency", brought out a rule nobody had written down: the daily limit is assessed on the franc equivalent, at the day's rate. The rule went into the product documentation and is waiting for its own scenario. The developer asked what becomes of the limit at midnight: it resets at the bank's end-of-day close, which will add a GIVEN line the day that case is written. One last candidate, the limit raised by telephone through the client advisor, falls outside the increment's scope: it is entered in the backlog and stays unshaped, for want of a behaviour to deliver this time round.
Visualisations
The technique produces structured text, lines and keywords, so both artefacts render as tables: the grid of the four keywords with their match in the unit test and the set of scenarios in the preceding section, which is the deliverable. Two ideas call for a drawing instead. The first is the threefold use of the same text, an example that becomes a scenario from which three arrows leave, towards the documentation the business reads, towards the acceptance criterion attached to the backlog item and towards the test replayed at every integration. The second is the three-role session, with the question proper to each role and the "what if" questions that give rise to the missing scenarios.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Low | Getting three people around one backlog item. No tool is needed to start. The one condition is that the business has cases it has lived through to tell. |
| Execution | Medium | The session is repeated for each backlog item and the "what if" questions take time by their nature. To that is added, once, the wiring of the scenarios to the test code and to the integration pipeline. |
| Documentation | High | The suite of scenarios is living documentation, which has to be paid for. Every rule change forces rewriting, deleting and rereading; without that the suite loses the readability that justified its existence. |
Tooling
The starting point is a whiteboard or a shared text document during the session. A scenario is short text and the template fits in four words: the useful constraint is to make it visible to everyone.
Backlog management tools (Jira, Azure DevOps, GitLab and their equivalents) hold the scenarios as acceptance criteria of the item they belong to. This is the cheapest place while automation is not yet in play, because the scenario follows the item through prioritisation and through the end-of-iteration demo.
Specification by example tools (Cucumber, SpecFlow, Behat, JBehave and their equivalents) read scenario files and bind them to test code. They also supply the measures that writing alone does not give: which scenarios are covered, which fail, which requirements are left without a scenario. Their syntax conventions differ, and the one to pick speaks the language of the team's platform.
Two additions count as much as the test tool. Version control keeps the scenario files with the code they specify, so that a change of behaviour and its specification travel in the same commit. The continuous integration pipeline replays the suite at every code delivery and drops a scenario that has become false before a reader relies on it.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.2 Behaviour Driven Development: the framing for the business analyst, the three elements (examples, the Gherkin grammar, execution), the single WHEN rule, the Three Amigos session, the use of the scenario as the acceptance criterion of a story and the limitations stated, the missing scenario for want of "what if" questions, combinatorial explosion and the upkeep of the suite.
- Dan North, Introducing BDD, Better Software, March 2006: the source of the technique. The shift from the vocabulary of testing to that of behaviour, the "given, when, then" template formulated with Chris Matts for requirements analysis and the language shared by analysts, testers, developers and the business.
- Agile Alliance, What is BDD (Behavior Driven Development)?: the attribution of the technique to Dan North and Chris Matts and the placing of BDD among the practices of test driven development and acceptance test driven development.