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.
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.
“No plan survives contact with the enemy.”
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.
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?
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
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.
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 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…
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.
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.
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?”.
Enjoy and happy testing!