This chapter explains that an example in behavior-driven development should be concrete, precise, and easy to verify. A good example is built from three parts: the context before the behavior happens, the action that triggers the behavior, and the outcome that shows what happened afterward. The key idea is that examples are not abstract descriptions; they use real values and specific details so everyone can clearly understand the intended behavior.
At the same time, examples should not be overloaded with irrelevant detail. Each example should focus on one rule and include only the concrete information needed to illustrate that rule. The chapter emphasizes that requirement workshops are about quickly exploring understanding, not about producing exhaustive test coverage, so the amount of detail should be just enough to clarify the requirement. Extra coverage and broader testing concerns can be handled later by the delivery team.
The chapter also makes a distinction between rules and examples: rules describe behavior in a concise, abstract way, while examples illustrate those rules in specific situations. Neither one replaces the other, and both are needed to document expected behavior well. If an example seems to cover several rules at once, it is usually better to split it into smaller examples that each highlight a single rule, making the discussion clearer and the specification easier to understand.
Anatomy of an example
Address change rule
State diagram of the order process showing the states in which an address change is possible
Examples for the address change rule
Positive example of the order state rule
Positive example of the valid address rule
Summary
All examples have three parts: context, action, and outcome. When creating an example it can be helpful to start with the desired outcome and work back towards the required context.
Examples need to be concrete to allow us to explore the requirements in detail.
The purpose of these examples is to reach a shared understanding of the work that needs to be done, not to provide exhaustive testing.
Rules and examples work together – both are equally important.
Each example should focus on illustrating a single rule.
FAQ
What is the structure of a concrete example in BDD?A concrete example is typically made up of three parts: context, action, and outcome. The outcome describes the expected state after the behavior occurs, the action is the triggering event, and the context is the starting state before the action.Why should examples be concrete rather than generic?Examples should be concrete so they unambiguously illustrate how the system should behave. Concrete details such as real values, usernames, dates, and amounts remove ambiguity and make the example specific enough to verify in the real system.Should every example include all possible context data?No. An example should include only the concrete data directly related to the rule being illustrated. Irrelevant details make examples long and boring, and they distract from the behavior being specified.How do I know when I have enough examples?You have enough examples when they sufficiently clarify the rule and help the team understand the requirement. You do not need examples for every possible state or combination; exhaustive coverage is more of a testing concern than a requirement workshop concern.Why is it important to focus each example on a single rule?Focused examples make workshops clearer and more efficient. When an example mixes multiple rules, it becomes harder to see which rule is being illustrated, so splitting it into separate examples often improves understanding.Can one example illustrate more than one rule?Yes, an example can accidentally or naturally satisfy multiple rules, but that is not ideal for requirement discovery. It is better to rewrite or split it so that each example primarily illustrates one rule and keeps attention on that rule.Do examples replace rules in BDD?No. Examples illustrate rules, but they do not replace them. The rule gives the concise, abstract description of expected behavior, while the example provides a precise, concrete illustration.Why is it not enough to have only examples?Without the rule, it can be difficult or impossible to infer the intended behavior from examples alone. The rule and the examples work together: the rule states the expectation, and the examples clarify it.What kind of mistakes can examples help catch?Examples can expose misunderstandings in requirements, such as confusion over boundary conditions or incorrect assumptions about when a behavior should be allowed. They also help ensure the team and business mean the same thing.Why shouldn’t the workshop turn into exhaustive test design?The requirement workshop should stay focused on understanding and clarifying the requirement, not on testing every possible combination. Exhaustive coverage and detailed test design are better handled by the delivery team outside the workshop.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
Effective Behavior-Driven Development ebook for free
