concept feature file in category BDD

This is an excerpt from Manning's book BDD in Action Second Edition MEAP V04. Login to get full access to this book.

In Gherkin, the requirements related to a particular feature are grouped into a single text file called a feature file. A feature file contains a short description of the feature, followed by a number of scenarios, or formalized examples of how a feature works.

Scenarios are organized in feature files and can be annotated with tags to indicate cross-functional concerns and to coordinate test execution.

This is an excerpt from Manning's book BDD in Action: Behavior-Driven Development for the whole software lifecycle. Login to get full access to this book.

In Gherkin, the requirements related to a particular feature are grouped into a single text file called a feature file. A feature file contains a short description of the feature, followed by a number of scenarios, or formalized examples of how a feature works.

Scenarios are organized in feature files and can be annotated with tags to indicate cross-functional concerns and to coordinate test execution.

5.5.1. The scenarios go in a feature file

The role of a scenario is to illustrate a feature, and you place all the scenarios that describe a particular feature in a single file, usually with a name that summarizes the feature (for example, earning_points_from_flights.feature). In JBehave, these files conventionally use the .story suffix (earning_points_from_flights.story), whereas the Gherkin-based tools use the .feature suffix. These files can be read and edited in a simple text editor, though plugins also exist for most modern IDEs. During the rest of the chapter, we’ll refer to these files as feature files, regardless of the file suffix used.

As you saw in chapter 2, these scenarios are part of the project’s source code, and they’ll be placed under version control. Many teams write the feature files during the “Three Amigos” sessions (see the “Different types of conversations” sidebar in section 4.5) and store them in the source code repository at the end of the meetings.

The exact file structure used to store the feature files varies from tool to tool. For example, figure 5.6 illustrates a typical Cucumber/Java project, whereas figure 5.7 shows the equivalent story files in a JBehave project.

Figure 5.6. Feature files are stored in plain text files as part of the project source code (this example is from a Cucumber project in Java).

Figure 5.7. Organizing feature files into folders makes them easier to manage and navigate. In this JBehave project, the features are organized by high-level capability.