What We Just Learned

It might seem like the system we’ve been building here is just a toy. There aren’t any concrete components that a user could interact with yet: our CashSlot is just a plain old Ruby class, and there aren’t any buttons for the user to push. What we do have, though, are the beginnings of a domain model and a greater understanding of the problem. Outside-in doesn’t always mean starting with the user interface; it means starting with the outside of whatever you want to discover.

We know it is not always possible to work like this. You will often be adding tests to a legacy system or working on a project where the user interface is already well-defined by the time you are asked to develop the code. Even in these situations, trying to model your domain in Ruby classes will help your own understanding and also make the test code more maintainable in the long term.

Here are some of the more concrete subjects we’ve covered in this chapter:

• Transforms help with maintainability by removing annoying duplicate code to process captured arguments from steps. They also give names to the useful parts of your regular expressions.

• Ruby code that supports the step definitions can go into features/support, which is loaded before the step definitions.

• The file features/support/env.rb is loaded first of all, and that’s where you need to boot up your application. This file isn’t loaded during a dry run.

• It’s good practice to organize step definition files with one file per domain entity.

• Step definitions execute in the context of an object called the World. You can pass state between steps using instance variables and mix in helper methods defined in Ruby modules.

By adding our own World module, we’ve made the step definition code easier to read, and we’ve started to decouple the step definitions from the system. The benefit of this decoupling will come later as the system itself evolves. In fact, in the next chapter, we’ll show you how we can introduce a web user interface for withdrawing the cash without having to change a line in the step definitions.

Try This

There are lots of places you could take this example now that we have it up and running. Here’s one idea for you to try:

The Big Rewrite

Now that we’ve discovered the domain model together, why not see whether you can do it again, for practice? Delete everything except the feature, the transform, and the step definitions. Then delete the body of each step definition, and change it back to pending. Close the book, run cucumber, and off you go!

Try to forget about what we did, and enjoy the process of discovering a domain model for yourself.

Bug Hunt

There’s one remaining item on our to-do list, reminding us that we need to investigate why we originally designed the Teller#withdraw_from method to take two parameters, but we’re using only one of them.

See whether you can figure out what this inconsistency means, and think about what changes you’d like to make in order to resolve it. Play with the code and try some solutions. We’ll work on this issue at the beginning of the next chapter, so you won’t have long to wait if you’re not sure of the answer.

Edge Cases

We have a single scenario here for the happy path through the process of withdrawing cash. Can you think of some simple variations on the scenario that would cause a different outcome? For example, what would happen if your account had a lower balance?

Write your new scenarios out in the same cash_withdrawal.feature file, and if you’re up for the challenge, have a go at automating them.