A narrative acts as a communication enabler, and scenarios are the result of that communication. They should describe interactions that the role (specified in the Narrative section) has with the system. Unlike unit tests, which were written as code by developers for developers, BDD scenarios should be defined in plain language and with minimum technical details so that all those involved with the project (developers, testers, designers, managers, customers, and so on) can have a common understanding about behaviors (or features) that will be added to the system.

Scenarios act as the acceptance criteria of the narrative. Once all scenarios related to the narrative are run successfully, the job can be considered done. Each scenario is very similar to a unit test, with the main difference being the scope (one method against a whole feature) and the time it takes to implement it (a few seconds or minutes against a few hours or even days). Similarly to unit tests, scenarios drive the development; they are defined first.

Each scenario consists of a description and one or more steps that start with the words Given, When, or Then. The description is short and only informative. It helps us to understand, at a glance, what the scenario does. Steps, on the other hand, are a sequence of the preconditions, events, and expected outcomes of the scenario. They help us define the behavior unambiguously and it's easy to translate them to automated tests.

Throughout this chapter, we'll focus more on the technical aspects of BDD and the ways they fit into the developer's mindset. For broader usage of BDD and much deeper discussion, consult the book, Specification by Example: How Successful Teams Deliver the Right Software by Gojko Adzic.

The Given step defines a context or preconditions that need to be fulfilled for the rest of the scenario to be successful. Going back to the book's administration narrative, one such precondition might be the following:

Given user is on the books screen 

This is a very simple but pretty necessary precondition. Our website might have many pages, and we need to make sure that the user is on the correct screen before we perform any action.

The When step defines an action or some kind of an event. In our narrative, we defined that the administrator should be able to add, update, and remove books. Let's see what should be an action related to, for example, the delete operation:

When user selects a book 
When user clicks the deleteBook button 

In this example, we multiplied actions defined with the When steps. First, we should select a book and then we should click on the deleteBook button. In this case, we used an ID (deleteBook) instead of text (Delete the book) to define the button that should be clicked. In most cases, IDs are preferable because they provide multiple benefits. They are unique (only one ID can exist on a given screen), they provide clear instructions for developers (create an element with an ID deleteBook), and they are not affected by other changes on the same screen. The text of an element can easily change; if this happens, all scenarios that used it would fail as well. In the case of websites, an alternative could be XPath. However, avoid this whenever possible. It tends to fail with the smallest change to the HTML structure.

Similarly to unit tests, scenarios should be reliable and fail when a feature is not yet developed or when there is a real problem. Otherwise, it is a natural reaction to start ignoring specifications when they produce false negatives.

Finally, we should always end the scenario with some kind of verification. We should specify the desired outcome of actions that were performed. Following the same scenario, our Then step could be the following:

Then book is removed 

This outcome strikes a balance between providing just enough data and not going into design details. We could have, for example, mentioned the database or, even more specifically, MongoDB. However, in many cases, that information is not important from the behavioral point of view. We should simply confirm that the book is removed from the catalog, no matter where it is stored.

Now that we are familiar with the BDD story format, let us write the book store BDD story.