Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin — Thomas Sundberg — 2016-12-04
Sometimes I see questions asking for flexibility in Gherkin, the language used by Cucumber. The purpose is often to remove duplication. An example may be this Stackoverflow question
Removing duplication is often a very a good thing. It is, however, sometimes better to keep duplication and gain clarity and readability.
Gherkin is a language for describing a wanted behaviour. It lacks a few properties. It doesn't support repetition nor does it support conditions. This means that it isn't suitable as a programming language. It is, however, great for describing concrete examples. An example may be
Scenario: a few cukes
Given I have 42 cukes in my belly
When I wait 1 hour
Then my belly should growl
This is very concrete. There is no ambiguity. It is also very inflexible. It doesn't accept a parameter as a method in a programming language might do.
This concrete example is great for communication. It is not so great as an implementation of a calculator.
What should you do then if you want to test a system and minimize duplication and maximize expressiveness? The short answer is, use better tools than Cucumber and Gherkin. Cucumber is not meant to be used for testing, it is meant for communication. If you want the flexibility of a programming language, use tools like JUnit for testing a Java system.
The litmus test for deciding on the tooling is: Who will have to understand this?
If the answer is non developers, use Gherkin with very concrete examples. Concrete examples are most likely not comparing things in a database. Concrete examples tend to describe external, observable behaviour of the system.
If the answer is developers, then use a test framework where you have access to a programming language. This allows for much more flexibility than Gherkin is designed to offer.
Gherkin is not a programming language. It is a language used for communicating between developers and non-developers.
I would like to thank Malin Ekholm for proof reading.
RSS