chapter seven

7 Cleaning up an old scenario

 

This chapter covers

  • The BRIEF acronym for writing good scenarios
  • Using example maps to improve a scenario
  • How scenarios provide specification and documentation
  • Focusing on communication rather than testing

Gherkin is used by thousands of organizations all over the world, and it is common to find long, complex and unreadable scenarios in their projects. Unfortunately, long, complex and unreadable scenarios do nothing to promote shared understanding across your organization and lead to constant maintenance efforts for your team. Cleaning up such a scenario not only alleviates these problems but also provides a good opportunity to learn more about your domain.

In this chapter you’re going to learn the basics of formulation by following the WIMP team as they take a poorly formulated scenario and make it better. We look in more depth at applying BDD to legacy projects in Chapter 11, “Coping with legacy”.

7.1 The old scenario

The Where Is My Pizza (WIMP) application lets customers place orders that they will collect from the restaurant (customer-collection). The customer can also choose to pay for the order when they collect it (pay-on-collection). There have been some problems with orders that are never collected or paid for. Patricia, the product owner (PO), has been asked to deliver a feature intended to reduce this problem, so she’s trying to understand the existing implementation of the customer-collection and pay-on-collection features.

7.2 Keep your scenarios BRIEF

7.2.1 The goals

7.2.2 The principles

7.3 Using example maps to provide focus

7.4 Document the essence of the behavior

7.5 Scenarios should read like a specification

7.6 Use real data when it provides clarity

7.7 Communication, not testing

7.8 Illustrative scenarios

7.9 Summary