TA Basics: Gherkin basics

Ruby + Cucumber is utilizing the Gherkin language so users can write scenario's and match them to actual scripts. The Cucumber + Gherkin combo is a widely used standaard among test automation engineers, but it has nothing to do with vegitables. So what is it? How to use it? And how to use it properly?/lessons learned.

What is Gherkin (and Cucumber)?

Let's start with the definition that is mentioned on the Cucumber(software) wikipedia page. 

"Gherkin is the language that Cucumber uses to define test cases. It is designed to be non-technical and human readable, and collectively describes use cases relating to a software system."

So not only do you write your test cases in a way even a non-technical person can read and understand what the test is actually doing. It can also be used as documentation. An example of how to write test cases using the Gherkin language you see in the picture of this post. This documentation on it's own does not execute anything, it only describes scenario's/use cases/examples. For the execution of the test we need Cucumber. Cucumber is an open-source tool for executable specifications. It will map the scenario's written in Gherkin with (a set of) actual steps to execute. You could say that Gherkin s the bridge between writing scenario's in a understandable way and executing steps.

Construction

In the most basic scenario a Gherkin scenario is covered by three individual steps. A precondition step that explains where the user is (Given....). A interaction step that explains the action the user is performing (When....). And a validation step that explains the expected end result (Then....). So all you need to remember is that for any scenario you need a Given, a When and a Then.

How to write scenario's

There are many ways and methodologies to define scenario's. For example with specification by example, the three amigo or example mapping. Choose whatever fits your project best. But there are some best practices you should keep in mind if you want to do it good from the start. This does not need to be in the phase of writing them down on paper, but it does make sense to use the best practices when you actually start use them in your test automation framework.

Lessons learned

Along the way you learn and pick up best practices. So here is a list to keep in mind that will help you write better scenerio's.

1. Write the given step in such a way it described what needs to be ready before you start the actual test
2. Try to avoid multiple 'Given' steps to keep it readable
3. Try to avoid many 'When' steps (multiple steps might mean you actually need multiple scenario's)
4. Try to avoid a first person style of writing, instead use the third person ("When I...." versus "When the user....") 
5. Describe the function instead of every action ("When the user clicks on the logout button" versus "When the user logs out")
• Example: It leaves more space for interpretation, so when you describe navigating to a page, on desktop this could be click where mobile needs a slide or a tab. The actual solution you solve with the code behind it, not in the scenario. I'll come back to this in a later blogpost about mobile test automation
6. Use variables instead of absolute values
• Example: Imagine testing on different environments with different data and the following scenario ' When the user reopens ticket "15"' . Now on the other environment ticket "15" might not excist but it's now "16". So it's better to put this info in a config file and rewrite the scenario to something like 'When the user reopens "the closed ticket"'.
7. Scenario's should stay readable, try to avoid element id's or classes in the scenario's, instead describe what you see
8. Avoid Steps within steps. This actually goes a bit more towards the technical part instead of Gherkin only and steps that refer to other steps are allowed but not best practice. Instead build functions and re-use those in steps (more about that in a later blogpost)

In simple projects you might want to skip some of these best practices. It's totally up to you to find a good balance between best practice and time you have to build your test suite. Just always keep in mind that when you apply these best practices it might take a bit more time in the initial setup, but you save time in the long run.

An ex-collegue of mine (Gijs), from which I learned the test automation basics, wrote two blogposts about Gherkin as well some time ago, which was an inspiration for this blogpost. So definatelly check those out as well.

• How to write Gherkin scripts a straightforward example (2017 August)
• The 3 most common mistakes writing Gherkin features (2018 March)