What is Cucumber?
Cucumber is a tool that utilizes a syntax called Gherkin, which makes acceptance criteria and test cases accessible to all interested stakeholders, technical and not so technical alike. The official Cucumber documentation explains:
That sounds cool, but what is that Gherkin thing you mentioned?
Gherkin is a plain English, human-readable syntax that defines who the audience is, what action is to be taken and what the expected outcome should be. It looks something like this:
Given I am a user on Google, when I search for, “How wonderful is the Gherkin language?” then I should be directed to the “Google Search Results” page, and I should see, “How wonderful is the Gherkin language?” in the search field.
This use case is pretty self-explanatory, right? That is the point! The really simple, easy-to-understand, self-explanatory point.
I like what I’m reading but I don’t quite understand what this has to do with quality assurance…
Quality assurance (QA) ensures the feature you developed is what the stakeholders (business analysts, product owners, etc.) wanted. Gherkin provides a means for stakeholders to define their acceptance criteria. The development and QA teams can digest the criteria to determine whether the end result matches what was intended.
Generally, business analysts will not provide every individual use case. This is where QA comes in. QA can take the high-level acceptance criteria and create all the various lower-level test cases. They can write these test cases in Gherkin syntax. This provides some stellar benefits.
- Test cases become visible and accessible: Anyone on the team, technical or not, can read the test cases and understand what is being tested.
- Test cases written this way encourage test case review sessions with your team: When everyone in the audience is on the same page and not bogged down by technical details, it’s easier to keep an objective view of what the feature under test is expected to do. This promotes communication. Test cases defined in plain English can raise new questions that require changes to the feature.
- When the stakeholders provide acceptance criteria, test cases can be written in tandem, or even prior to development: If you need to make changes, they can be caught early during test case review sessions, before development is complete.
- These test cases will act as documentation for the feature under test: No more relying on one person to explain how some part of the system works. No more spending hours explaining to a new hire how the product works. No more remembering to go back and update Wikis when features are updated (more on this in a moment).
Back to Cucumber. Remember Cucumber?
The test cases written in Gherkin are written in what is called a feature file. This is basically a plain text file that Cucumber can consume. Cucumber has bindings in several different coding languages which allows those test cases to become automated test cases. Without getting too deep into the specifics of how to implement Cucumber, each of the steps (Given, When, Then) from the Gherkin scenarios are translated into code that programmatically achieves the step.
For example, “Given I am a user on Google,” will have a step definition implementation that will open a browser and load google.com. From a technical point of view, there are additional tools that are required to achieve this but that is for another blog post!
One of the collaborative features of Gherkin/Cucumber is you can have one person write out all the test cases in the feature file and have a different person implement the automated code for each test case. This may benefit your team if it has someone who is less technical or doesn’t have the time capacity to write the automation themselves, but who can be responsible for test case writing. Perhaps you have someone else who is more technically-savvy but not as strong in creating test cases who can be responsible for developing the automation. Gherkin/Cucumber provides resource flexibility.
Cucumber makes test cases that were written in Gherkin automatically executable! They should not require tests to be run manually. That is yet another benefit of Cucumber: you define the tests once and they can run repeatedly.
Those wonderful Gherkin tests written during feature development then go on to become part of the regression suite. You can run with a click of a button, thanks to the automation integration with Cucumber. If a feature changes, but perhaps the QA team was not informed, it will become evident because one or more tests will fail. This should prompt conversation. Either a change was made unintentionally, or it was made intentionally and the test case – which is also acting as feature documentation, keep in mind – gets updated so the tests pass again.
I’m intrigued and want to learn more!
Glad to hear it! Please check out these helpful resources:
- Official Cucumber website
- Cucumber book (with examples in Ruby)
- Cucumber book (with examples in Java)
- Google / YouTube search “cucumber tool” to find more helpful resources, tutorials and examples in one of the many language bindings supported by Cucumber
