BDD/Cucumber Basics: Make Your Business Rules Concrete; Leave Your Implementation Details Abstract

Choosing the right level of concrete vs. abstract will help you derive the most value from Cucumber and BDD.

I recently attended an amazing Cucumber workshop. During the training Aslak Hellesoy, the inventor of Cucumber, used a simple exercise to encourage people to make their examples more concrete. He would ask for someone to name a feature of an app and then ask “Can you give me an example?” Often, the examples given were high-level and abstract at first, so he’d keep asking “Can you make it more concrete?”, driving the person to include detail in their example.

Concrete examples are a key to writing good Cucumber scripts because they drive the discussion that is so vital to the success of BDD and Cucumber. After all, as Liz Keogh has said, “BDD uses examples in conversation to illustrate behavior.” Examples help make the scripts readable, more like conversation, and are more likely to help us discover the interesting parts of the application. 

For instance, let’s say we have a not-so-concrete user story: “As a user, I want to deposit a check.” That’s pretty abstract. But when we elaborate this into something more concrete, we might get:

Given Paul has a checking account, with a balance of $151.00
When Paul deposits a $101.50 check
Then Paul should have a checking balance of $252.50

This is a much more elaborate and detailed example. If we were unfamiliar with how the mechanics of a check deposit work, it would be easily discerned. If there were special business rules around this (say the bank takes 5% of a check deposit), they would be explicitly stated as we talked through the specifics of an example.

However, there is a bit of difficulty here, especially for beginners. Often, when we ask people to make their examples more concrete they will immediately start to talk about implementation details instead of business rules.

In our example above, they might mention things like Paul taking a picture of the check, or Paul navigating to a specific page on the website, or screen within the app. But while our examples are meant to tell a readable story in a way, we obviously will be leaving out some details like what our fictional user had for breakfast that day.

So how do we decide what to make concrete and what to leave abstract or implied?

The best rubric is to make the business rules concrete, while leaving implementation details abstract. Here are three reasons why this will help in your Cucumber practice:

Business rules drive the implementation

Discovering business rules is the core goal of using Cucumber. One of the biggest problems in software is developing a solution first, and then trying to fit your problem into what you’ve solved (a variant of the Golden Hammer anti-pattern).

Cucumber helps us make sure we understand the problem first and then progress to implementing a solution. By leaving your implementation details out of Cucumber scripts, you avoid the problem of letting your implementation drive your business rules.

More reusable scripts

If implementation details are removed from your scripts, they are vastly more reusable across more systems. Take our check deposit example above. We could use that example to test an iOS/Android/Windows Phone app that uses direct camera capture, an upload function on a website, or even how an ATM processes the physical check inserted into it. As soon as the scripts start mentioning pages or touches explicitly, we lose that interoperability.

More readability

Another core goal of using Cucumber is to have something that all of the Three Amigos – Business Analyst, Tester, Developer – can easily read and understand. Eliminating unnecessary details around the specific implementations avoids adding jargon that may not be universally accessible.

By making your business rules as concrete as possible, you’ll reap a lot more benefit from Cucumber – but be mindful to leave the implementation details abstract or hidden.