3 What is an Example?
This chapter covers
- The structure and purpose of a concrete example
- How to know when you have enough examples
- How rules and examples work together
- Focusing each example on a single rule
In the previous chapters, we explored the role of examples in a BDD approach. You may have wondered: “Are examples really enough to specify a feature? How many examples do we need to specify a feature?”
In this chapter, we’re going to answer these questions.
3.1 How hard is concrete?
We all know what an example is, but when it comes to creating concrete examples that unambiguously illustrate how a system should behave, we need to ensure they’re good examples. It’s best to think of an example as being an artifact divided into 3 parts - context, action and outcome, as shown in figure 3.1 - and to think of these in the opposite order.
Figure 3.1 Anatomy of an example
The outcome is a description of the state of the system after the behavior we’re interested in has taken place. It should contain enough detail so that we could actually go and check that the system has behaved according to our expectations.
The action is the event that causes the behavior we’re interested in to take place. It might be some action by a user, but equally it might be an input from another system, a scheduled job, or any other stimulus that can cause the system to react.