What We Just Learned

We’ve taken a quick skim over a lot of different things in this chapter, all of which will be covered again in more detail later. Let’s recap and highlight some of the most important points.

Directory Structure

Cucumber likes you to use a conventional directory structure for storing your features and step definitions:

You can override this structure, if you really want to, by passing arguments to Cucumber, but this is the conventional and simplest way to store your files.

Baby Steps

As we progressed through the example, did you notice how often we ran cucumber?

One of the things we love about working outside-in with Cucumber is how it helps us to stay focused. We can let Cucumber guide us through the work to be done, leaving us free to concentrate on creating an elegant solution. By running Cucumber every time we make a change, any mistakes we make are found and resolved quickly, and we get plenty of feedback and encouragement about our progress.

Gherkin

Cucumber tests are expressed using a syntax called Gherkin. Gherkin files are plain text and have a feature extension. We’ll talk more about Gherkin in Chapter 3, ​Gherkin Basics​.

Step Definitions

Step definitions are the Ruby glue that binds your Cucumber tests to the application you’re testing. When the whole thing plays together, it looks a bit like the figure ​here​.

You’ll learn more about step definitions in Chapter 4, ​Step Definitions: From the Outside​.

After that whistle-stop tour of Cucumber’s features, we’re going to slow down and get into a bit more depth. We’ll work our way in through the layers over the next few chapters, starting with a look at Gherkin, the language we use to write Cucumber features.

Try This

See whether you can add a second feature, division.feature, using the other example from the start of this chapter. Do you need to change the solution to make it pass?