Join Robin Beck for an in-depth discussion in this video Building the right thing, part of Behavior-Driven Development.
- [Instructor] The primary goal of BDD is to build the right thing, but that's not an easy goal by any means. When starting a new project, many times it can seem like what is desired from stakeholders is fairly straightforward. In reality, the complexity of the system requirements and acceptance criteria become more and more apparent throughout the application lifecycle. This can easily lead to wasted time writing unnecessary code and even products that users don't use, or stress that gets transferred to developers as the team needs to rethink requirements that might change a fundamental part of the application.
In his essay, No Silver Bullet, legendary computer scientist and architect Fred Brooks states, "The hardest part of building a software system "is deciding precisely what to build." It must be stressed that BDD is not designed to help you discover what particular product to create. And you don't use BDD to come up with idea for the next big app or service. Product owners should have a clear conception of what the product is.
Rather, BDD is a tool for correctly building the best product that you can, that end users will love, or at the very least, a reliable product that does what it's expected to. There are a number of starting points that must be addressed before you begin the BDD process. First, business stakeholders and product owners should have clearly communicated about what should be produced. Acceptance criteria for the product should be mostly fleshed out, although BDD will help to refine this even more.
And finally, your user stories should have already been defined. So what can we do when there's ambiguity regarding our acceptance criteria? While there are a number of methods for facilitating conversations to clarify our acceptance criteria, one particularly simple and effective method is known as example mapping. It is critical for developers to fully understand acceptance criteria before they take a user's story and start writing tests around it. For us to fully discover our acceptance criteria, it's necessary to have conversations to explore the problem domain.
If you're having trouble, example mapping helps us keep these conversations short and on track by creating a visual representation of a user story to guide and document the discussion. The process of example mapping is fairly straightforward. Using a four-color pack of index cards, we build a visual representation of our user's story with each color providing a specific piece of information. We build this as we have our conversation to document what is discovered through the discussion about the user's story.
We begin with a yellow card, which contains the name of our story itself and place this at the very top. Our blue cards represent specific rules that constrain the scope of our story. This is our acceptance criteria. With green cards, we provide concrete examples of the user's story in the context of a specific rule. So we place these under the relevant blue card. And finally, we have our red cards. These cards contain questions that cannot be immediately answered during the discussion, but are captured so that we can move on with the conversation.
With this method of example mapping, you flesh out and refine your user's stories, and hopefully, in the process, truly articulate your acceptance criteria for development while determining further information you need in order to build the right thing. To learn more about example mapping, check out the Cucumber docs. So where should the process begin? Because BDD places a large emphasis on conversations, it is a best practice to have these discussions closer to the moment you plan on actually writing your tests and code.
If you have these conversations too far ahead of building the system, much of the context and specifics can be lost over time. Often, we simply forget the details of these conversations, so try your best to time this appropriately. Some BDD practitioners, like Matt Wynne from the Cucumber project, insist that these conversations should happen at the last responsible moment before software development begins so that you start your project with a clear understanding of where it should be going.
- What is behavior-driven development?
- Agile and BDD
- BDD examples
- BDD frameworks
- Defining scenarios
- Domain modeling
- Enforcing object-oriented design
- BDD process: Behavior before function