BDD Glossary: Terminology, Core Concepts and Definitions

A unit of work stated from the point of view of whoever benefits from it, usually in the form: as a role, I want a capability, so that a benefit follows. The third clause is the one that gets dropped and the one that carries the value.

One concrete example of a behaviour, with real values rather than descriptions. A scenario names a single situation and a single outcome; two outcomes means two scenarios.

The free prose under a Feature heading that states who wants the capability and why. Not executed, and worth writing anyway, because a narrative nobody can complete is a feature nobody can justify.

A capability with business value, holding the scenarios that pin down how it behaves. One feature per file is the usual granularity.

What the person asking for a story actually gets. Stated in the so-that clause. A story whose benefit restates the capability has not identified one.

The kind of user a story speaks for. Roles keep scenarios honest by forcing the question of whose behaviour is being described, which often reveals that two roles were being conflated.

The conditions under which the people who asked for the work agree it is done. In BDD the scenarios are the acceptance criteria, rather than a separate list that can drift away from them.

The measure of whether a delivered capability achieved the benefit it promised. Distinct from acceptance criteria, which only establish that it works as agreed.

The scenario in which nothing goes wrong. Necessary and never sufficient: a feature documented only by its happy path has recorded the least contested part of its behaviour.

A story whose beneficiary is the development team rather than a user, such as replacing a library. Legitimate, and worth stating in the same form so the benefit still has to be named.

The stakeholder for work whose value is technical. Naming one prevents technical stories from being treated as self-justifying.

The first BDD principle: business and technology should refer to the same system in the same way. Two vocabularies for one system is a defect, not a translation layer.

The second BDD principle: any system should have an identified, verifiable value to the business. Where nobody can say what a feature is worth, the useful response is to find out rather than to build it.

The third BDD principle: up-front analysis, design and planning all have a diminishing return. Enough is enough, and the examples get written just before the work.

The practice of completing analysis and design before implementation begins. The term is generally used critically, as the thing enough-design-up-front is measured against.

The various formulations the practice has been given since 2006. They differ mostly in emphasis: some lead with the conversation, some with the executable examples.

Applying example-based thinking during requirements work, before any decision to build. In practice the same conversation, held earlier.

Letting a design emerge under the pressure of successive examples rather than settling it in advance. The design equivalent of enough design up front.

A rule of thumb from extreme programming: implement the least that satisfies the current example. It is a constraint on speculation, not an argument for carelessness.

The observed arc by which developers learn test driven development, ending in the realisation that the practice was about specifying behaviour rather than testing. The observation BDD was built on.

Statements of what a system must do. BDD replaces the statement with an example, on the grounds that a statement can be agreed without being understood.

Constraints on how a system behaves, such as response time or availability. Expressible as scenarios where a threshold can be named, and awkward where it cannot.

The structure of the concepts a system deals in. BDD and domain-driven design meet here, because a shared vocabulary is a shared model whether or not anybody draws it.

Sequential analysis, design, build and test. Used in BDD writing as the contrast case, particularly for how requirements are captured once and then interpreted repeatedly.

Continuing to analyse past the point where analysis adds information. What the diminishing-return principle is guarding against.

Keeping only documentation that earns its maintenance. Executable specifications qualify because they fail when they stop being true; prose describing behaviour generally does not.

How expensive it is to alter behaviour later. The argument for BDD is that most of this cost comes from misunderstanding rather than from code, and a conversation is cheaper than rework.

The family of iterative practices BDD sits inside. BDD does not require any particular agile method, but it does assume work arrives in small increments.

Building in repeated short cycles, each producing something that works. What makes it possible to write examples just before the work rather than months ahead.

Merging and building the whole system frequently, so that executable specifications are checked continuously rather than at the end. Without it an automated scenario suite has no mechanism to act on failure.

Delivering to real users often. Shortens the gap between an agreement about behaviour and evidence about whether it was the right behaviour.

The team size at which a single shared vocabulary is achievable. The three-amigos conversation stops working when the number of people who must agree grows past a handful.

How a cycle is arranged so that the conversation, the examples and the implementation each have a place. In BDD the distinguishing feature is that examples are agreed before implementation starts, not after.