Cucumber and Gherkin are not about flexibility

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.

What is Gherkin?

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.

A litmus test

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.

Conclusion

Using the right tool for the job is essential. Cucumber and Gherkin are great in some cases and rubbish in others. The decision to use Gherkin or a programming language to describe the behaviour of a system is a matter of audience. A non tech audience may prefer reading Gherkin, a tech audience may prefer code.

Gherkin is not a programming language. It is a language used for communicating between developers and non-developers.

Acknowledgements

I would like to thank Malin Ekholm for proof reading.

Resources



(less...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
Executable specification
Gradle
J2EE
JUnit
Java
Linux
Load testing
Maven
Mockito
Pair programming
PicoContainer
Programming
Public speaking
Quality
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS