3 What is an Example?
This chapter explains that concrete examples are central to Behavior-Driven Development because they help teams clarify what a system should do in specific, unambiguous situations. A good example is made up of three parts: the context, which describes the system state before something happens; the action, which triggers the behavior; and the outcome, which describes the expected result. These examples should use real, specific data where it matters, but they should not include unnecessary detail that distracts from the rule being illustrated.
The chapter emphasizes that examples are primarily a discovery tool, not an attempt to exhaustively test every possible case during a requirements workshop. Teams need enough examples to expose misunderstandings and confirm shared understanding between business and delivery stakeholders, but not so many that the conversation turns into detailed test design. Broader test coverage and edge-case analysis are still important, but they are better handled later by the delivery team rather than during collaborative requirements exploration.
The chapter also clarifies the relationship between rules and examples: rules provide concise, abstract descriptions of expected behavior, while examples make those rules concrete and harder to misinterpret. Examples should not replace rules, because it is often difficult to infer the general rule from examples alone. Ideally, each example should focus on a single rule, even though it may rely on other rules being satisfied, and teams should split overly broad examples when doing so improves clarity and keeps the discussion focused.
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 are the three parts of a concrete example in BDD?
A concrete example is made up of three parts: context, action, and outcome. The context describes the state of the system before anything happens, the action is the event or stimulus that triggers the behavior, and the outcome describes the expected state of the system afterward.
Why should examples be thought about in the order outcome, action, then context?
Thinking about the outcome first helps clarify what behavior you want to observe and verify. Once the expected result is clear, you can identify the action that causes it, and then define the context needed before that action occurs.
What makes an example “concrete”?
An example is concrete when it uses specific, precise data rather than vague descriptions. It should include actual values such as names, dates, addresses, amounts, order states, or other details needed to run through the example and verify the expected behavior.
Does every example need to include all possible system data?
No. An example should include only the concrete data directly related to the behavior being illustrated. Large systems may require lots of background data, but examples should avoid unnecessary detail so they remain focused and understandable.
How many examples are needed to specify a rule?
There is no fixed number. You need enough examples to clarify the rule and remove important misunderstandings. During requirements discovery, the goal is not exhaustive testing but shared understanding between the business and the delivery team.
Should requirement workshops try to cover every possible case?
No. Exploring every possible combination belongs more to software testing than requirements discovery. In a workshop, examples should help the team understand the requirement. Detailed test coverage can be handled later by the delivery team using testing techniques such as equivalence classes or classification trees.
Are examples alone enough to specify system behavior?
No. Examples illustrate rules, but they do not replace them. Rules provide a concise, abstract description of the expected behavior, while examples provide concrete illustrations that make the rules harder to misinterpret.
Why should rules be recorded along with examples?
Rules should be recorded because it is not always possible to reverse engineer the intended rule from examples alone. A good specification includes both the rule and the examples that clarify it.
What is the difference between focusing on a rule and utilizing another rule?
An example may need to satisfy or utilize other rules in order to work, but it should focus attention on one rule. For example, an address-change example may use a valid address, but if the purpose is to illustrate whether the order state allows an address change, then address validity is not the focus.
What should you do if one example illustrates multiple rules?
If an example appears to illustrate multiple rules, consider splitting it into several shorter examples, each focused on a single rule. This often reveals that some data is essential for one rule but unnecessary for another, making the examples clearer and easier to use.
Effective Behavior-Driven Development ebook for free
