Chapter 5
Expressive Scenarios

In Chapter 3, ​Gherkin Basics​, we deliberately didn’t give you the whole story and showed you just a core set of keywords instead. They’re the fundamental building blocks you need to get started working with Cucumber, and we wanted to get you started as quickly as possible. Now it’s time to refine your skills.

When you’re writing Cucumber features, make readability your main goal. Otherwise, a reader can easily feel more like they’re reading a computer program than a specification document, which is something we want you to try to avoid at all costs. After all, if your features aren’t easy for nonprogrammers to read, you might as well just be writing your tests in plain old Ruby code.

The real key to expressive scenarios is having a healthy vocabulary of domain language to use to express your requirements. That said, using only the basic set of Gherkin keywords can often make your features repetitive, making them cluttered and awkward to read. By the end of this chapter you’ll know everything there is to know about Gherkin’s syntax, giving you all the tools you need to write clear, readable Cucumber acceptance tests. We’ll also show you how to use tags and folders to stay organized as you write more features for your project.

First we want to concentrate on helping you remove that repetitive clutter. We’re going to show you how to use scenario outlines and data tables to help make your Gherkin scenarios more readable, but we’ll start with a new keyword called Background.