Where Gherkin sucks

5 min readMay 6, 2021

Is there actually an advantage or can it be a useless waste of time? And if nobody wants to communicate using Gherkin, can I still use it in my nice automatic tests?
What if the PO started using Gherkin as a form of communication to QA and DEV?

Do The Simplest Thing That Could Possibly Work
- Kent Beck

It’s been a while since Dan North & Co. started to disclose how and how much three simple given-when-then magic words could help not only Developers in coding the “what” into software but also Business in a clear definition of the “what” and the QA also in defining the tests (“how”) that is, precisely what should happen if that “what” receives a certain input.

Over the years, dozens of tools have been born that help each of these actors (the three amigos) to do their part based on the Ghekin written arm in arm with the others (at least hopefully so).

Starting from (grandfather) FitNesse and continuing through Specflow, JBehave passing through the Cucumber framework ecosystem that accompanies and supports us up to the “nodejs-generation” of tools for the development of automatic tests such as WebdriverIO, Nightwatch, Appium, Cypress which in themselves would test even without the gherkin written on the “.feature” files. In fact, Cucumber becomes an additional software layer (node package) that fits into our automatic tests and allows us to represent the shape, structure and results of the tests in Gherkin style. But is it really necessary to add an extra layer to our automated tests? Is there actually an advantage to write the Gherkin or can it be a useless waste of time? And if nobody wants to communicate using Gherkin, can I still use it in my nice automatic tests?

From these questions (and from the extensive literature on the subject) it is immediately clear that Gherkin can be used, indeed, it was created to be used as a means of communication in the different phases of the SDLS (Software Development Life Cycle), starting from the analysis of requests from POs (or other stakeholders), up to manual testing, automatic testing and development (whether in TDD or not). Each “amigos” puts his own and the scenarios written in gherkin grow. But if no one is “comfortable” in communicating in gherkin-mode, can I use the gherkin? Let’s see the different points of view.

DEVELOPER

In Unit Tests it is quite simple to insert the three magic words given-when-then through comments, indeed it helps us to orient ourselves and keep the focus of our tests which are thus always divided into three very specific sections. Furthermore, if we do not have to add cucumber (or other libraries that interpret the “.features”), the project remains lean and the UTs remain quite speaking having care in the nomenclature of the tests (which would then be scenarios) and files, but the reports will hardly be human-readable so if the users of the UT are DEVs only, I don’t see any particular contraindications in writing gherking-style unit tests.

QA

Nobody understands Gherkin but as a QA I would like to write the Test Case in Gherkin.
If the QA needs to write, describe and deliver Test Cases, then most likely it does so because it is a project requirement and this documentation will have to be read by others (PO, customer, etc.) of course it is not required in the Scrum framework. But if the POs and the Customers are willing and accept this type of documentation, then that’s fine but it will have to be maintained and updated manually so let’s remember that one of the advantages of BDD is living documentation and not manual-documentation.

QA Engineer

As we have seen before, there are many frameworks that hook the code that does the dirty work of automatic tests with “.feature” files (cucumberjs for example) but this implies a considerable effort in creating and maintaining automatic tests using this further layer of software obtaining in the end only two advantages:

Human-readable reports: these frameworks produce Html reports (or Json which are then almost always transformed into html or pdf) very well done, full of information of any kinds and which tell what each test did step by step, how long did it take etc. This advantage is really an advantage if and only if someone reads and understands this live documentation, in addition to who produces them, that is the QA Engineers or who writes the automatic tests.
Reusability of step gherkins. An intrinsic prerogative of these frameworks is that it is possible to implement a certain step only once and then reuse it in different features and scenarios. “Unfortunately”, this is a feature that methods and functions of different programming languages also have, so even without gherkin we can somehow reuse pre-written pieces of automatic test code.

Here we are in a bottom-up situation where the BDD only drives automated tests but it could help other stakeholders as well. So unless you QAEs have someone who needs clear and unambiguous automatic test reporting, cucumber can be a very unhelpful implementation effort.

PO and Customer

What if the PO started using Gherkin as a form of communication to QA and DEV?
Let’s take a step back. Since the Agile movement is the fashion of the moment and there is even a manifesto, let’s use it! At one point it reads

“Individuals and interactions over processes and tools”

which means that first of all we should consider how our three amigos have to communicate with each other.
So, going back to Gherkin, apart from a slight initial learning curve — after all it is a matter of pigeonholing what we want in three magic words — there would certainly be an increase in clarity and a decrease in ambiguity in the wishes exposed by the PO towards the QA and DEV. Furthermore, the QAs would be better directed to designing the various unhappy-paths of the scenarios and the DEVs better addressed to the development and automation of the scenarios even if automating the tests is only one of the benefits of the BDD but it is not the main purpose.

Here we are in a top-down situation in which we start from the Customer and his needs, in order to arrive at a description of the scenarios, from the first and simplest one to the most particular and complex one. The three amigos are aligned and have participated in the drafting of these scenarios that could be automated or not depending on the needs and strategies.
The important thing is that our friend, Mr. Gherkin, has taken on his fundamental role above all: everyone must clearly understand the needs of the stakeholder through real life examples and not hypotheses of magical software that works for who knows what witchcraft.

Where Gherkin sucks

DEVELOPER

QA

QA Engineer

PO and Customer

Mobile Test Automation

Learn to automate your native iOS app tests with Detox tool and Javascript

Further Reading

Written by Alessandro Arcella