I hope you found my previous blogs (Introduction to KarateDSL and Setup & configurations) in the Karate series to be informative and helpful. I’m back with the third blog in this series, this time focusing on the technical concepts of feature files used to create test cases based on requirements. In this post, we’ll take a close look at various methodologies of Gherkins and how they’re implemented.
Steps to create a Feature file
Before we get into the code structure and methodologies, let’s take a look at how to create a feature file for writing test cases.
- A feature file can contain several test cases.
- Put all of your test code and objects in the
src/test/java folder and create a package under it.
Step 1: Right-click on the folder > New.
Step 2: Click on File.
Step 3: Append “.feature” to the end of the filename, for example, testFile.feature.
And Your feature file is now ready for use. Wasn’t that easy?
Gherkin Methodologies along with script structure
Karate scripts are written in Gherkin format, with Feature, Background (optional), and Scenario as the key sections.
Furthermore, the test steps are written in the Given-When-Then format.
Let’s look at the specifics of each keyword.
- Feature: The Feature keyword’s aim is to group similar scenarios and provide a high-level overview of a software feature.
Feature should always be the first primary keyword in a Gherkin document, followed by a “:” and a brief description of the feature.
- Background: There are often a few steps that are duplicated in “Given” steps across all scenarios in a Feature file.
You can transfer these repetitive Given steps to the “Background” section followed by a colon (:).
At the same level of indentation as the first Scenario/Example, a Background is placed before it.
- Scenario: Scenario is simply a summary of the test case; it may also be left blank.
As per cucumber documentation, Each line that isn’t a blank line has to start with a Gherkin keyword, followed by any text you like. The only exceptions are the feature and scenario descriptions.
Scenarios are structured in the following way:
- Describe an initial context (by using
- Describe an event (by using
- Describe an expected outcome (by using
- Add conditions to your Given, When and Then statements. (by using
Sample JSON Response:
“name”: “Cinema - ABC”,
“name”: “Cinema - PQR”,
“name”: “Cinema - XYZ”,
- Scenario Outline: The Scenario Outline keyword can be used to run the same Scenario several times with various combinations of values. It must be used in combination with the “Examples:” keyword to input values for tagged columns using the “<column_name>” delimited parameters.
It is used for Data Driven Tests.
Scenario Outline is a very strong keyword that allows us to dynamically match response values, enabling us to check complex scenarios.
The text after “Given” describes the context, the “When” keyword includes a Http method (such as Get, Post, Put, Delete, Patch, Options, Head, Connect, Trace), and the “Then” keyword refers to the API response code which can be 2XX,4XX or 5XX depending on the scenario.
Depending on the requirement, the statements after “Then” keyword can typically include the following types of response validations:
- Various types of matches like match ==, match !=,match contains etc.
- Fuzzy matching by using #notnull, #string, #array, #present, #object, #boolean etc.
- Schema validations for smart comparison (i.e. structure validation can be done on JSON payload).
- When an expression evaluates to a boolean value, assertion becomes a best choice.
I’ll wrap up this blog by mentioning Gherkin’s essential keywords that are majorly used are Feature, Background, Scenario, Given, When, Then, and And. We’ll look at more concepts in Karate DSL over the next blog.
Did you find this blog to be useful? Please share your thoughts in the comments section below, and don’t forget to click the Follow button to receive the latest updates. You can reach out to me via LinkedIn.
Until then, stay safe and keep learning!!!