liveBook · Manning

Feature file

As explained in BDD in Action, Second Edition

A feature file is a plain-text Gherkin document that describes one software feature and its scenarios.

A feature file keeps the examples for one software feature together. It is a plain-text Gherkin document with a Feature title, an optional description of the business objective, and one or more scenarios. Business stakeholders can read the expected behavior, while BDD tools can use the same scenarios as executable specifications. section 2.3.5 section 7.2.1

Feature: Transferring money between accounts
  In order to manage my money more efficiently
  As a bank client
  I want to transfer funds between my accounts whenever I need to
  Scenario: Transferring money to a savings account
    Given Tess has a current account with $1000
    And a savings account with $2000.00
    When she transfers $500 from current to savings
    Then she should have $500 in her current account
    And she should have $2500 in her savings account
 
  Scenario: Transferring with insufficient funds
    Given Tess has a current account with $1000
    And a savings account with $2000.00
    When she transfers $1500 from current to savings
    Then she should receive an 'insufficient funds' error
    Then she should have $1000 in her current account
    And she should have $2000 in her Savings account

The money-transfer feature puts a successful transfer and an insufficient-funds case in one file. Each scenario states the starting accounts, the attempted transfer, and the expected result. section 2.3.5

To write a useful feature file:

  • Name the user activity with Feature, then briefly state why it matters. Put text between the title and first scenario in the feature description. section 7.2.1
  • Turn each concrete example chosen for automation into a scenario. Include straightforward behavior, alternatives, and edge cases. section 7.4.2
  • Use Given for preconditions, When for the action, and Then for expected outcomes. Use And or But where they make the steps easier to read; use an Examples table for repeated variations. section 2.3.5

Keep the file aligned with the feature, not a temporary user story or release. Feature files conventionally end in .feature, live in the source repository, and can be grouped into directories by business capability. In a Java project, src/test/resources/features is a common location. section 7.4.1 section 7.4.6

A scenario in a feature file states business outcomes rather than the mechanics of interacting with the application. Running it before step definitions exist produces a pending or failing test, not a working check. Step definitions connect its steps to automation; once automated and executed, the file and its reports can serve as living documentation. section 3.5.2 section 16.1

How BDD in Action, Second Edition covers it

How deep it goes
Explains titles, descriptions, scenarios, step keywords, tables, naming, and organization; distinguishes an executable specification from a working automated check.
Examples
Uses money transfers, train departures, frequent-flyer points, and capability-based directory layouts to illustrate content and organization.
What it assumes
Introduces Gherkin structure from plain-English requirements and requires no specialized editor.
What you can do after
Practice/perform writing and organizing feature-level Gherkin scenarios, then connect them to automated acceptance tests.
How it connects
Connects Gherkin scenarios and acceptance criteria to step definitions, business capabilities, and living documentation.

Also explained in

Compare how 3 books explain feature file →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of BDD in Action, Second Edition. The section links point to the parts of the book it draws on.