When using Cucumber for automated testing I try to ensure my Gherkin uses ubiquitous language so the business and development team share a common language. But the Gherkin must also be DRY. This not only saves confusion but also saves development effort.
Gherkin anarchy
I assumed my team would realise that:
- ubiquitous language not only meant the business and development team sharing a common language but also different sub-teams using the same language. Particularly in the Gherkin.
- developers would reuse Step Definitions created by other developers.
Assumptions are dangerous and, after some time, I found I’d been mistaken. To my horror I found my Gherkin had several different ways of saying the same thing. Despite using “business language” in a general sense each business analyst and developer was using slightly different phrases. And then each developer implemented their step definitions using their variation of the language.
So rather than one Step Definition for “Given I have an order”, to ensure an order existed for this scenario, I had a bunch. All achieving the same thing but in slightly different ways. Different language backed by different code.
Given I have an order
Given there is an order
Given there is an order called “incidental detail”
Given the order “incident detail” exists
Given an order exists
Gherkin anarchy. This was bad for a couple of reasons:
- Anybody reading the Gherkin would assume these language differences were significant (they weren’t)
- I had paid people to do work they shouldn’t have done
And this kind of Gherkin is WET.
Write Step Definitions once, and reuse
Luckily John Kelly is lazy – in a constructive way. He picked up his first scenario to implement and asked “Why are we all creating different Step Definitions for the same thing?” (Which was news to me.)
John wasn’t willing to play that game so he wrote a master set of Step Definitions. The language of this new set was agreed by all the business analysts (the main scenario writers). And we mandated use of the new Step Definitions.
I did end up with variations on “Given I have an order” but the the differences were real and the language obvious:
Given I have an order
Given I have an order with a “[Header]” of “[Value]”
Given I have an order with the following values:
Given I have a new order with the following values:
The resulting Step Definitions meant my Gherkin was DRY.
Andy Hunt and Dave Thomas invented the DRY principle in their book “The Pragmatic Programmer” (Wikipedia: Don’t Repeat Yourself). The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” However “don’t repeat yourself” is a pretty good summary. The opposite to DRY is of course WET, commonly taken to stand for either “write everything twice” or “we enjoy typing”.
Clearly my development team had enjoyed typing. Now we try not to repeat ourselves.
This post is part of a series on Specification by Example.