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.
The above code looks like a nice general purpose bit of glue code to handle a when step. Here are some when steps:
Do you get the sense that the above steps are really written as a text based version of:
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.
- 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:
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?
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.
Gherkin is not a programming language.
When it starts to look like one, rephrase back in human form, then simplify, then it’ll suit everyone.