Cucumber was developed to assist testing in a Behaviour Driven Development (BDD) environment. Since the primary function of BDD is to facilitate the communication between business and developers; Cucumber was created to fill in the gap between business and testers. 

Don’t let analysts write Gherkin scenarios

Most projects will try to use Cucumber to allow business analysts to add testing scenarios. Meaning that the stories will show some Cucumber steps, which the tests should include in the automated tests. These steps are written in the Gherkin language, so they would be, or should be readable by everyone. 

So business analysts will start writing Gherkin to facilitate testing? Well, that’s the plan. To paraphrase from field manual “Truppenführung” of Helmuth Karl Bernhard Graf von Moltke: 

“No plan survives contact with the enemy.” 

Helmuth Karl Bernhard Graf von Moltke

Strangely and perhaps important to note: Letting business analysts write scenarios comes with both benefits and downsides, as I’ll explain in this blog.

It is usually counterproductive to let product owners and business analysts write Gherkin. 
Yet this has been the case for every project that I’ve been working with Cucumber. 

Advantages of using Cucumber in BDD

So we’ve established that there is a plan: fill in the gap between business and testers.
So what are the advantages of using cucumber. Why do we continue to use this in so many projects? 

Readability promotes teamwork

Considering the plan, we know that cucumber and Gherkin are readable and can promote teamwork. These do go hand in hand, as one cannot live without the other. And as you can see this is very readable. 

Scenario: Breaker guesses a word   
  Given the Maker has chosen a word   
  When the Breaker makes a guess 
  Then the Maker is asked to score 

Reusability decreases necessary steps

Another major advantage of cucumber is the reusability of the steps. For example: 

Scenario: Breaker guesses a number   
  Given the Maker has chosen a number   
  When the Breaker makes a number   
  Then the Maker is asked to score 

There is no need to create a new step or even a new function in the code for the last step. As long as the code behind the step is sufficiently generic, the reusability will be a significant asset. 

Automate your tests by using example tables

The third advantage, that I want to cover is that of example tables.

At the moment, we have two scenarios, with some duplicate lines. This can easily be solved using the example table. Now I have one scenario outline that will run twice. Once using the word value and once using the number value. 

Scenario outline: Breaker guesses a <game>   
  Given the Maker has chosen a <game>   
  When the Breaker makes a guess   
  Then the Maker is asked to score 
 
Examples: 
    | game   | 
    | word   | 
    | number | 

While the benefit of example tables cannot be overstated, writing code that is adapted to handle every scenario that you can think of might not be worth the gains. This will always depend on the application and the result. 

Gherkin is easily adopted

Gherkin is defined as a domain-specific language, meaning that it has no other application than cucumber. With its 16 keywords, the language is simple and quick to be adopted. 

While given when then steps are the bread and butter of Gherkin, these keywords do not influence the code. They are created and used for readability. You could write the following and it would still work. 

Scenario: Breaker guesses a number   
  When the Maker has chosen a number   
  When the Breaker makes a number   
  When the Maker is asked to score 

The keywords are used to subdivide the text into prerequisites, actions and, expected results. Commonly this subdivision is seen as a major advantage of Cucumber, due to the increase in readability. Hence its location in the blogpost. Yet commonly seen as an advantage, does not prove that it is. On to the drawbacks… 

Drawbacks of Cucumber in BDD

The herculean task of generic yet specific code

The whole cucumber – Gherkin combination adds another layer of complexity. Suddenly besides writing generic enough functions in Java or JavaScript, the developer or tester or analyst must write steps that can be reused while being specific enough to differentiate between the scenarios. 

Generic but specific enough, which does sound like a herculean task. And it is an increasingly difficult task. Every time a new feature is ready for testing, all current steps have to be checked to see if they can be used. 

Teamwork reduction

This does reduce the amount of teamwork possible. Because the steps written by the analyst might require some change to be specific enough or to be generic enough to be reused. And we cannot expect someone not dedicated to the testing framework, to know all currently available steps. Or how the code behind the step works. So now, an analyst is advising steps rather than providing them. Meaning that in the end, steps might have to be changed or discarded. 

My humble opinion

Cucumber is more trouble than it is worth. The major advantages are readability and communication between analysts and testers. And I just do not accept that those advantages are worth the trouble cucumber brings. Communication between testers and analysts is vital as a tester or any quality-minded person. If you need cucumber to facilitate this, you have bigger problems. 

The other advantage is the reusability of the steps. Yet keeping the steps reusable is a difficult and time-consuming task. So maybe it is just not worth the effort. 

I’ve done several projects that were using cucumber, yet never have I seen it used beneficially. 

The business has never asked me about my step definitions or anything the like. The only question business asks is: “Are you ready for production?”. 

Yours truly

Enjoy and happy testing! 

Sources 

Cucumber HomePage 
Dutch Java-magazine discussing Cucumber 
Cucumber scenario Outline