With all the buzz around Gherkin lately, have you found yourself “in a pickle” trying to figure out just what it is? Or how it relates to software testing? Or why you should even care?
In a recent blog, HPE ALM Octane: Fact or Fiction, Karen Spencer hinted at one reason you should care. Among its many new features for supporting modern software quality practices, HPE ALM Octane embraces a new way for structuring tests. It utilizes Gherkin.
What is Gherkin?
Simply put, Gherkin is a well-known syntax for writing tests that implement the behavior-driven development (BDD) methodology, which is itself an extension of test-driven development (TDD). If you’re unfamiliar with BDD and TDD, but want to know more, the internet abounds with great resources to help you understand their basic principles, so I will not cover them here. Just note that the emphasis of BDD and TDD is on testing.
Gherkin lets you write your test scenarios in plain-text English (or one of 60+ other languages), plus it provides a little extra structure to help you concisely illustrate business rules in real-world domains. The Gherkin test below describes one behavioral flow of a shopping application. It is simple, clean, and easy to understand.
The keywords at the beginning of most lines add the structure.
- Feature – Describes context. It is often written like a user story: As a [role] I want [feature] So that [benefit]
- Background – Adds context to the test scenarios within a single feature
- Given – Puts the system in a known state before anyone/anything interacts with the system
- When – Describes the key action the user performs
- Then – Describes outcomes to be observed
By convention, the Gherkin document describes one feature and all the scenarios needed to test that feature. You don’t need anything more than a text editor to create Gherkin documents, although many tools can help with that, including HPE ALM Octane. HPE ALM Octane lets you compose and store your Gherkin test scenarios there, and it provides a manual runner for executing them manually and having the results stored and tracked.
Moving into Automation with Cucumber
While you obviously can run through a Gherkin test scenario manually, it is really intended to be used within a test automation framework. Cucumber is such a framework and an open-source one at that. Cucumber allows the execution of Gherkin documents or “feature files.” It doesn’t know how to execute your test scenarios out-of-the-box, so you must translate the plain text Gherkin steps into coded actions that interact with the system. These are called step definitions.
As a test automation engineer working in an IDE like Microsoft Visual Studio or Eclipse, you’ll first need to import the Cucumber libraries. Next, import your feature file and then you can begin creating your step definitions. For example, here is a typical Gherkin statement.
And here is the corresponding step definition using Cucumber syntax and the Java code for automating the test step.
Naturally, your step definitions could include automating interactions with your application’s user interface, in which case you might include HPE LeanFT or Selenium method calls. This recently published movie shows the end-to-end process of setting up and using Cucumber and LeanFT to automate Gherkin test scenarios: LeanFT Cucumber.
Once you’ve finished implementing your automated tests, check them into your favorite source repository, for instance Git. At this point, they can be run as part of your continuous integration/continuous testing process. If you use Jenkins for that, a Jenkins plugin is available to have any test results automatically pushed into HPE ALM Octane.
Summary
The introduction of HPE ALM Octane is raising awareness among traditional HPE ALM/QC users about popular methodologies like BDD and useful tools like Gherkin and Cucumber. If you want to know more, I encourage you to explore further. Here are some resources to get you started:
- The Cucumber Book: Behaviour-Driven Development for Testers and Developers
- Gherkin Wiki
- Cucumber Wiki