Chapter 7
Step Definitions: On the Inside

It’s time to pull together everything that you’ve learned in the first part of the book and use it in practice. There are a few advanced concepts left about Cucumber that we want to explain to you, and they’ll be much easier to demonstrate with an example. A lot of what we’ll do in this part of the book will blur the line between testing and development. If you’re more of a tester than a developer, don’t let that worry you: the Ruby code we’ll build is just about as simple as it gets. By following along, you’ll get a good sense of how we like to work, as well as pick up some new knowledge about working with Cucumber.

At the end of ​Returning Results​, we’d just started work on a greenfield project to build the software for an ATM. We had a single scenario for the most important behavior of the system: letting someone walk up to the machine and withdraw cash.

Now we’re going to pick up this scenario and work outside-in, designing the system as we go, just as we would on a real project. In this chapter, we’ll get the scenario to pass by driving out a simple domain model for our ATM. Then, in the next chapter, we’ll get a nasty surprise when we discover that there’s a missing step in our scenario. Finally, we’ll demonstrate the benefits of well-engineered test code by introducing a user interface around the domain model.

By the end of this chapter, you’ll have learned about Cucumber’s World and how you can use it to contain state that’s shared between step definitions. We’ll write some custom helper methods that will introduce a layer of decoupling between our step definitions and the application we’re building. We’ll show you how to use transforms to reduce duplication in your step definitions and make their regular expressions more readable. Finally, we’ll show you how we like to organize the files in our projects so that they’re easy to work with and maintain.