What Is a Feature File?
A Feature file is a BDD file written in Gherkin that describes application behavior in terms of business scenarios. It's a text file with a .feature extension used in frameworks like Cucumber, and it acts as acceptance criteria to drive automation.
- Purpose: describe business requirements in a readable format and serve as acceptance criteria for automation.
- Contains: a Feature description, Scenarios or Scenario Outlines, and steps written with Given/When/Then.
- Real-project usage: business analysts or QA write Feature files during sprint planning; QA automates them by mapping to Step Definition methods; tests execute using Selenium and integrate with Jenkins.
- Tools used: Cucumber, Selenium WebDriver, Java, Maven, TestNG/JUnit, Jenkins.
The Structure of a Feature File
A Feature file is written in plain English using Gherkin syntax so QA, developers, and business stakeholders can all understand it.
The basic structure:
- Feature: describes the functionality under test.
- Background: common preconditions for all scenarios.
- Scenario: a specific test case.
- Scenario Outline: used for data-driven testing.
- Given: precondition.
- When: action.
- Then: expected result.
- And / But: additional steps.
In real projects, feature files are reviewed by Product Owners and mapped to step definitions for automation.
Analogy from your notes: like writing the steps for a recipe in simple English.
Real project: In an e-commerce project, separate feature files were created for Login, Add to Cart, and Checkout.
Feature, Scenario, and Scenario Outline
- Feature explains what functionality is being tested — written at a high level, usually mapping to a business requirement (e.g., Login Functionality, Payment Feature).
- Scenario defines one specific test case under a feature, using Given–When–Then (e.g., Login with valid credentials).
- Scenario Outline is used when the same test case runs with multiple data sets — it works with an Examples table for data-driven testing (e.g., Login with multiple invalid usernames and passwords), reducing duplicate scenarios.
Analogy from your notes:
- Feature = Movie
- Scenario = One scene
- Scenario Outline = The same scene with different actors
Scenario vs Scenario Outline
- Scenario is used when only one set of input data is needed — it executes once and is simple to read.
- Scenario Outline is used when the same test logic needs to run with multiple data sets — it uses placeholders and an Examples table, supporting data-driven testing and reducing duplication.
Real project: "I used Scenario for valid login and Scenario Outline with Examples for invalid logins. In our insurance project, we used Scenario Outline to test login with multiple credential sets."
The Examples Keyword
The Examples keyword is part of Scenario Outline, providing the test data.
In the scenario steps you use placeholders like <username> and <password>, and during execution Cucumber replaces them with values from the Examples table — each row executes the scenario once with different data.
It's what enables data-driven testing in BDD.
Real project: "In our fintech project, we used Examples to validate login error messages across multiple credential sets."
Example shape:
Scenario Outline: Login with invalid credentials
Given User is on the login page
When User enters "<username>" and "<password>"
Then Error message should be displayed
Examples:
| username | password |
| user1 | wrong1 |
| user2 | wrong2 |Background: What, When, and the One-Per-Feature Rule
Background defines common preconditions that run before each scenario (including each row of a Scenario Outline). It avoids repeating the same Given steps in every scenario.
When to use it
When multiple scenarios under the same feature share the same preconditions — put those steps in Background instead of repeating them.
Best practice
Background should contain only preconditions, not actions or assertions.
Real project: In an e-commerce project, Background was used to navigate the user to the login page before each login scenario.
Can we have multiple Backgrounds?
No — Cucumber allows only one Background per feature file, which runs before every scenario.
If you need conditional setups, the approaches are:
- Split scenarios into multiple feature files.
- Use Hooks (
@Before) for conditional setup.
"I kept one Background and moved conditional setups to hooks using tags."
Reusing Steps Across Feature Files
Yes — step definitions can be reused across multiple feature files.
Step definitions live in common Java classes and are mapped by matching step text.
If the step text is the same, Cucumber maps it to the same step definition method.
Best practice: maintain common step definition packages.
Real project: Login steps reused across the Login, Order, and Profile feature files.
FAQs
What is a Feature File?
A .feature Gherkin file describing business scenarios as acceptance criteria, mapped to step definitions for automation.
What Does a Feature File Contain?
Feature, optional Background, Scenarios/Scenario Outlines, and Given/When/Then (plus And/But) steps.
What Is the Difference Between Scenario and Scenario Outline?
Scenario runs once with one data set; Scenario Outline runs the same logic with multiple data sets via placeholders and an Examples table.
What Is the Examples Keyword?
The data table for a Scenario Outline — each row runs the scenario once, replacing <placeholders> with values, enabling data-driven testing.
Can a Feature File Have Multiple Backgrounds?
No — only one Background per feature; use multiple feature files or @Before hooks for conditional setup.
Can Steps Be Reused Across Feature Files?
Yes — step definitions in common classes are matched by step text, so the same step text maps to the same method.