Tosca tester
Gherkin testing, Behavior Driven Development testing and writing test scenarios
When it comes to how to write tests and test software, teams have many options. How do you determine what syntax to use and what test solution is best for you? In this article, we’ll cover the use of the Gherkin language and Gherkin tests. We’ll cover the Gherkin syntax and how to write the test. Before we discuss what the Gherkin language is and how to write Gherkin test, we first need to understand the role of behavior-driven development (BDD) and how it and Gherkin work together.
What is BDD – Behavior-Driven Development ?
Behavior-Driven Development is an agile software development methodology in which the application is documented and tests are designed based on the behavior the user expects when interacting with the application. By encouraging developers and testers to focus only on the desired behavior of an application or program, it helps avoid excessive code, unnecessary features, or lack of focus for a given test or code. We can simply describe this development in two phases. Discovery and Testing. Before teams begin work, they first discover what they don’t know about the application. Then they better understand how to stick to the core features of the app and be more productive. When it comes to testing, the process of thinking about these tests starts before development begins. Tests are written to guide the implementation and the final product. 
Gherkin definition
Gherkin is a text-based language with a simple structure. It is designed to be easy to learn even for people who don’t know how to code, but it is structured enough to allow brief descriptions of test scenarios and examples to present business rules in most areas. Because the language uses plain English, it is designed to describe software system use cases in a way that almost anyone can read and understand.
Gherkin – syntax
Feature: scenario title Given [prepodmienky alebo setup testu]
When [trigger alebo akcia (event)]
Then [očakávaný výstup] For more information about the syntax, you can also check out Gherkin documentation.
How to write the Gherkin test
If you want to write Gherkin test cases, you first need to understand some of the keywords that are used and their practical meaning. Here is a list of the most common keywords in Gherkin syntax:
- function (feature),
- rule,
- example,
- given, when, then, and, but
- background,
- scenario outline.
Each keyword is critical to the process of writing the Gherkin test. Let’s now take a closer look at these keywords and how to use them when writing Gherkin tests.
Feature
Gherkin scripts begin with this keyword followed by text that provides a description. In simpler terms, a function is a description of what the software is supposed to do. This keyword is also used to group scripts. It’s not really for testing purposes, but it allows you to add documentation about requirements and business rules. The description section ends when you start a new line with one of the other keywords, such as a scenario outline, example, or rule.
Description
If necessary, you can also write free descriptions under the keywords, as long as none of the lines start with the keyword.
Rule
The keyword rule is used to express a single business rule that needs to be included. This provides context for the function.
Gherkin steps
Next, let’s look at some of the steps in the Gherkin tests. These are the Given, When, Then, And or But steps.
Given
Given set the scene for the scenario. In most cases, these steps describe something that took place in the past. This provides context to the system before the user interacts with it. For this reason, you should not include user interactions in this step. Think about what you include in this step as prerequisites. Note: You can have more than one Given step.
When
When stepis an action step. It describes an event. An example might be an event triggered by another system or user interaction. It is recommended that you have only one When step for each scenario.
Then
The Then step is the result step. Here you describe what you want the system to do, so that it can be compared to how the software actually works in practice. It should be something that you can actually see as a result, such as a report or message.
And, But
Once you have the above steps, you can use and or but.
Background
As mentioned above, the background allows you to add even more context to the scenarios in the function. Here you can have more than one given step as needed.
Scenario Outline
The scenario outline includes a section with examples. These steps read like a template. The scenario outline is run once for each line of the examples section except the header line.
Gherkin – Given When Then examples
The golden rule of Gherkin is simple: treat other code users the way you want them to treat you. Make functional files that are easy for everyone to understand. Write scripts in an intuitive way, and they should also not be ultra-declarative or ultra-imperative. Ultra-declarative example:
- It’s too vague.
- The steps are not procedural – they cannot be automated.
- It skips the conditions of success.
Ultra-imperative example:
- It contains too much detail.
- Interaction with the application at a low level.
Here is a proper example:
- The scenario has declarative, descriptive steps.
- The given-when-then order shall be followed.
- The interaction and desired behaviour are clearly illustrated.
- A specific example helps the reader understand the scenario.
Basic rule of BDD The cardinal rule of BDD is the one-to-one (1:1) rule – each scenario should cover exactly one single independent behavior. Focusing on one behavior at a given time provides several advantages:
- Greater clarity and less ambiguity.
- Each test failure identifies a separate problem.
- A less complicated script has a shorter execution time.
- It consists of one behaviour, one example, one situation, one test and one outcome.
Example of an incorrect scenario: It involves two separate behaviors (two When-Then pairs). If you have included two or more Given-When pairs in your test, it is better to split them into a different scenario. There are cases where it is more appropriate and acceptable to write multiple When-Then pairs, but in general this should be avoided. Unique example rule When it comes to test cases, sometimes less is more, so leave out the ones that aren’t necessary. Instead, focus on unique equivalence classes. Although testing “everything” may seem tempting, it’s a waste of time. Instead, focus on the most critical aspects of the project and minimize duplicate testing. Example: In the example above, the scenario would be run six times. Once for each row in the example table. This is completely unnecessary. The golden rule of grammar Because language is important, write as if your high school English teacher graded your grammar. The goal of scripts is to make them readable and brief. The steps are designed to be reusable. The benefits of behavior specification can be ruined by poor syntax, spelling errors, and inconsistent wording. Scenarios can be confusing. Example no. 1: The above scenario is inconsistent and ambiguous – it is not clear whether “I” am the “user” or whether a third party is involved. In addition, using only the third-person perspective is more elegant. Phrase the steps as you would write normal sentences. Example no. 2: We don’t know whether the steps above verify the existence of links or whether they are clicked on – we need to clarify them: Correct example: Write good titles With well-written scripts, creating strong titles is easy. An excellent script focuses on one specific action. The title should be a short one-volume text.
- Be careful when using phrases such as “and”, “or” and “but” as they imply that more than one action may be taken.
- The use of conjunctions such as ‘because’, ‘since’ and ‘so’ should also be avoided, as they explain why the scenario exists, whereas we should focus on what the plot is – answer to question why can be derived from the specific stages of test or described by comment or documentation.
- Avoid the language of assertion – don’t use terms like ‘verify’, ‘assert’ or ‘should’ as they focus on assertion rather than action.
Gherkin plugins and packages
If you want to make your life easier, install plugins or packages
Text editors with Gherkin
Syntax highlighting in Gherkin is supported by most popular text editors. Advanced Cucumber language support is available in some IDEs, including the ability to run Cucumber from within the IDE, display results, navigate between Gherkin phases, etc. Atom – This is a text editor for Windows, macOS and Linux that offers several different packages for use with Gherkin. TextMate – This is a dedicated text editor for macOS for use with Gherkin. It helps to enhance the documentation process when developing scenarios. Visual Studio Code – It is not a text editor but a code editor specifically designed for Windows, macOS and Linux. It can be used with the Gherkin syntax plugin. IDE – IDE is another plugin that can be used for various languages that are maintained as a plugin for Gherkin. There are various IDEs, such as:
- Java IDE(Java Eclipse IDE, Java Apache Netbeans IDE, Java IntelliJ IDEA),
- IDE for Ruby,
- CukeTest.
Advantages and disadvantages of using the Gherkin language
Now that you know how to write a Gherkin test, you may be wondering how to determine if this is the right option for you and your team. The truth is, there are both advantages and disadvantages associated with using Gherkin. Let’s take a closer look at some of them. Gherkin is simple Gherkin is inherently simple to understand for developers and business managers alike. In a sense, it’s “non-technical” language, which makes it easier to collaborate across teams. It focuses on the project requirements of the Gherkin Syntax Language, and this type of testing really focuses on project and business requirements. This ensures a development process designed with the user experience in mind. Code reuse The way these tests are written makes it easy to reuse parts of the code of other tests. This can help save time, money and resources. Not for all projects Gherkin + Cucumber is not ideal for all types of projects. Short projects that will require a lot of tests can be delayed by using this method. Although BBD has its time and place, this way of thinking and implementing these tests can slow projects down. Requires a lot of team involvement This can be a pro or con, depending on the team’s development methodology. As mentioned earlier, Gherkin and Cucumber go hand-in-hand with behavior-driven development. This means that it requires the team to constantly collaborate, which may not always be appropriate for a given project. Potential Expenses Although these tests can be easier to write, a poorly written test can result in a lot of wasted time and extra money if the tests need to be rewritten. Unless developers understand Gherkin very well, this type of testing can be a major financial risk.
Gherkin framework
Working effectively with the Gherkin language requires the right set of tools. These tools not only help in writing and organizing Gherkin scripts, but also in executing them as part of automated test suites. The most commonly used tools with Gherkin are:
- Cucumber: It’s the most popular tool for performing Gherkin scenarios. Cucumber supports a variety of programming languages including Java (check our article What is Java), Ruby, and JavaScript, making it versatile for different development environments.
- SpecFlow: SpecFlow, which is primarily used with .NET projects, is similar to Cucumber and follows the same principles. It integrates seamlessly into the .NET ecosystem.
- Behave: For Python developers, Behave is a good choice. It is designed specifically for Python and works well with Gherkin.
- Quantum – Quantum is an open-source Java-based BDD testing framework designed by Perfecto. Quantum’s automated BDD tests are executed in the cloud, making them stable on clean and secure Android/iOS devices and desktop browsers.
Conclusion
As mentioned earlier in this article, Gherkin is a fundamental language in the field of software testing, especially in the context of Behavior Driven Development (BDD). Its simple but powerful syntax allows teams to create clear, understandable, and executable specifications. Gherkin bridges the gap between technical and non-technical stakeholders, ensuring that software behaviour is closely aligned with business requirements and user expectations. In conclusion, Gherkin is more than just a language for testing; it is a means of improving the quality, efficiency and effectiveness of software development and testing processes. If you speak German and are an IT Tester Consultant Medior or IT automation tester, check out our employee benefits and respond to job offers.
