Saying it with Cucumbers

Ashley FriezeSeptember 22nd, 2020Last Updated: September 18th, 2020

0 36 2 minutes read

One of the biggest challenge of using Cucumber is non-technical.

Developers don’t like writing in natural language. It makes them wistful for programming languages. Similarly, folks in the business cannot necessarily write specs in a crisp style that makes them executable. The ideal is to partner with business and development to find a natural way of expressing things.

However, we want our Cucumber specs to be consistent, so they’re straightforward to implement. Ideally we want to explicitly focus on the important data for a particular scenario, but leave some data implicit.

If you’re writing cucumber step templates as though they’re function calls, you need to rethink.

Let’s look at a simple example of something where the average programmer gets blind-sided by the development aspect.

We’ll work backwards.

void whenAUserHitsTheHomePage(String login) {
   if (login.equals("IS")) {
      logUserIn();
   }
   if (login.equals("IS NOT")) {
      logUserOut();
   }
   goToHomePage();
}

The above code looks like a nice general purpose bit of glue code to handle a when step. Here are some when steps:

When the user goes to the home page and he IS logged in
When the user goes to the home page and he IS NOT logged in

Do you get the sense that the above steps are really written as a text based version of:

goToHomePage(true);
goToHomePage(false);

It’s borderline, isn’t it? I think the fact that we’ve defined a boolean like “parameter” in the middle of the Gherkin step is a clue that this has been written backwards from a function call perspective.

Maybe It’s Right or Wrong

In some cases, it’ll be clear that the natural language of the Gherkin has been twisted into a procedural programming style. In some cases, it MIGHT be the case that it has, or it might not.

It’s perfectly reasonable to use a regular expression to pick out keywords from the Gherkin step and use them to parameterise the action within the glue code.

But is it the right thing to do in our current situation?

How to Double Check

When faced with this question, let’s go back to the objective of writing Cucumber specs. We want to express, in the human of the user, what behaviour the system must display.

So:

Go back to basics and rewrite the different versions of the steps in the neatest human language
Ignore any refactoring and deduplication
Review the variations side by side
Only then consider if the phrasing contains common elements
Maybe turn into multiple glue code bindings, or maybe parameterise, based on what you find

In this example:

When a logged in user goes to the home page
When a user who is not logged in goes to the home page

Both of those seem more natural… but they’re different shapes. Is there another way of saying it? What’s a “user who is not logged in”? Are they even a user? Are they maybe anonymous?

When a logged in user goes to the home page
When an anonymous user goes to the home page

Now we can match (a|an) (logged in|anonymous) in the regular expression in the glue code and it’s both natural language AND gives us our boolean state.