Featuring the Feature Files
- Savithri Sivakumar
- Aug 29
- 4 min read
Jayasri Vijay
What is a Feature file?
In Cucumber BDD, feature files are plain text files with a ‘. feature’ extension that describes the behaviour and functionality of a software application using a specific syntax called Gherkin.
Why the name Gherkin?
Gherkins are a type of small cucumbers. In the same way, Gherkin language is a structured, yet simple component that forms the basis of Cucumber’s functionality. The name Gherkin provides the connection between the language and framework it serves.
Purpose of the Feature files
Feature files try to bridge the communication gap between business stakeholders, developers and testers. Gherkin writing is the foundational step in a Cucumber BDD project. The language used in this file should be simple yet descriptive, providing a clear idea of every feature to be tested in the application. Following best practices while writing Gherkins for multiple feature files, could help prevent certain exceptions while executing the step definitions.
Keywords in Gherkin
Feature: Describes the overall functionality or feature being tested.
Background: It describes the common prerequisite steps that should be executed before every scenario in the feature file
Scenario: Represents a specific test case or example of how the feature should behave.
Given: Describes the initial state or preconditions for the scenario.
When: Describes the action or event that triggers the behaviour being tested.
Then: Describes the expected outcome or result of the action.
And/But: Used to add additional conditions or exceptions within Given, When, or Then statements. ‘But’ keyword is commonly used for describing any negative scenario.
Scenario Outline: This keyword is to execute the same scenario multiple times, with different sets of data.
Location of feature files in Cucumber framework
In a Cucumber framework, the feature files must be placed in a folder under src/test/resources
Examples
(Sample Gherkin for https://dsportalapp.herokuapp.com/)
@stack
Feature: Testing all the scenarios in stack module
Background: The user clicks on the get started button of stack module after signing in to the ds algo portal
Given user signs into the portal using valid username and password following which navigates to the stack page
@Stackoperations
Scenario: Verify that the user is able to navigate to Operations in Stack page
When user clicks on operations in stack button of Stack module
Then user successfully navigates to the operations in stack page
@StackoperationsCodeEditor
Scenario: Verify user is able to open Try here page from operations in stack page
Given user is in operations in stack page
When user clicks on try here button in operations in stack page
Then user successfully navigates to code editor of the operations in stack page
@loginValidation
Scenario Outline: Login validation
Given User is on the login page
When User enters <username> and <password>
Then User should see the following <message>
Examples:
| Username | password | message
|user1 | pass1 | Welcome user1
|user2 | pass2 | invalid password
Best Practices for writing Gherkins
1. Background sets up a common prerequisite that runs before every scenario. Hence, it would be a good practice to use only Given under Background.
2. The statements following Given, When and Then keywords should be clear and concise. Try to keep the number of characters in each of these lines up to 100 or less. Each of this line will turn into a method name, when we generate step definitions from the feature files.
3. The scenarios must be written in a way satisfying the condition that, every scenario in Cucumber BDD should be running independent of each other.
4. It is important to make sure that statements following Given, When and Then keywords in one feature file should be unique from the statements used in any other feature file. Following this practice will help avoid any exceptions happening later when all the different feature files are run together.
5. Tags (eg., @StackoperationsCodeEditor) – having meaningful tag names will be helpful when we try to isolate certain scenarios or modules to run them separately.
Multiple Given/When/Then statements having same statement in a feature file
Example
@StackimplementationTryingEmptyEditor
Scenario: Verify user receives error while clicking on Run button without typing in code (implementation page)
Given user is in try here page of implementation page
When user clicks on Run button in Try here page without entering any code in the editor
Then user does not see any alert message saying code editor is empty
@StackimplementationTryingCodeWithError
Scenario: Verify user receives error while clicking on Run button after typing in a wrong python code (implementation page)
Given user is in try here page of implementation page
When user clicks on Run button in Try here page after entering a code with error in the editor
Then user gets an alert message about the error in code
In the above example, there are two Given statements that are same. In the same way, there could be multiple When statements or multiple Then statements that could be same. It is perfectly fine to have such matching statements within one feature file.
However, it is to be noted that, as mentioned earlier, having same statements in more than one feature file would not be best practice.
What happens when the statements are same for any particular keyword?
When we generate the step definitions for a feature file with repeated statements, there will be only one step definition method generated for multiple statements that are same.
Example:
For the Given statements in scenarios @StackimplementationTryingEmptyEditor and @StackimplementationTryingCodeWithError from above example, there will be only one common step definition generated. Both the given statements will be linked to the same step definition.
Now the next question could be,
Should I have such redundant lines in my Gherkin?
Yes, it is still required to write every Given, When and Then statements in a feature file. This makes the feature files better understandable. Skipping those lines could make the scenarios unclear.
Hope these points help answer some questions that arise while writing Gherkin for the first time.
Happy learning!
Thank you!
