What We Just Learned

Congratulations, you’ve graduated from Gherkin school! Let’s look back over what we’ve learned in this chapter.

• Readability should be your number-one goal when writing Gherkin features. Always try to sit together with a stakeholder when you write your scenarios, or at the very least pass them over for feedback once you’ve written them. Keep fine-tuning the language in your scenarios to make them more readable.

• Use a Background to factor out repeated steps from a feature and to help tell a story.

• Repetitive scenarios can be collapsed into a Scenario Outline.

• Steps can be extended with multiline strings or data tables.

• You can organize features into subfolders, like chapters in a book.

• Tags allow you to mark up scenarios and features so you select particular sets to run or report on.

Have you noticed that we’re going outside-in as we work through this part of the book? We started with an overview, then looked at the most useful bits of Gherkin, and then did the same for step definitions. Now that you’ve learned about the more advanced features of Gherkin, you’re almost ready to dive deep into step definition Ruby code. In the next part of the book, that’s exactly what we’ll do, with a worked example that will give you a chance to practice everything you’ve learned, and more. First, though, we’re going to take a step back and examine some of the common problems you and your team might encounter as you start to use Cucumber and what to do about them.

Try This

Review the scenarios that you’ve written for your system, and see whether you can find an opportunity to use a Background, a Scenario Outline, or a data table. Refactor the feature to make use of the new keyword and compare the new version of the feature with the old one. Which one do you think is more readable? Show it to someone else on your team; what do they think?