A feature file is a human-readable BDD specification that names a feature and records the scenarios expected to work. It turns a user-facing requirement into executable test intent: each scenario states conditions and actions with Given/When/Then language, while the implementation remains in separate step definitions. This makes the behavior understandable beyond the test code and keeps attention on what the application should do. section 2.4.4 section 4.3.1
A feature file does not execute by itself. Step definitions connect its sentences to pytest code: decorators match scenario text, parsed placeholders pass dynamic values into functions, and assertions check the result. For example, a statement that a record type should be 5 can supply 5 as a parameter, allowing similar scenarios to test other values without changing the basic step pattern. section 2.4.4
Use a feature file as a small, behavior-first testing workflow:
- Name the feature being tested, such as parsing a batch header or serving an API endpoint. section 2.4.4 section 4.3.1
- Write a clearly named scenario that communicates the expected behavior. section 2.4.4
- Describe the interaction with Given/When/Then statements, including setup when the scenario needs it. section 4.3.1 section 8.8.3
- Place the file in a features directory and load it from a corresponding step-definition test file. section 4.3.1
- Keep feature-specific steps separate when isolation helps run and maintain one feature independently. section 8.8.3
Listing 2.9 Parsing an ACH batch header
Feature: Parsing a Nacha Batch Header
Scenario: We have a record type of 5
When We parse the batch header
➥"5200Company name DiscretionaryData Company
IDARCComp desc 0216232302160471061000010000001"
➥ Then The record type should be 5
This compact feature file names a batch-header parsing feature and expresses one expected result: parsing the supplied header produces record type 5. section 2.4.4
Testing an API response
A feature can specify an API contract before or alongside its implementation. The /files scenario says that making a GET request to the endpoint should return status code 200. Its step definitions load the feature, issue the request through a test client, store the response in a fixture, and assert the declared status code. The feature states the behavior; the Python functions supply the mechanics. section 4.3.1
Listing 8.45 Our feature file and scenario
Feature: The /files/{fileId}/batches/{batchId}/entries endpoint
Test returning entries for a batch
Scenario: I want to check the entries for a Checking Application
Given that I have a clean database
And that I have posted the file "ppd-single-credit.ach"
When I request entries for a file and batch
Then I should have a response that includes all
➥ applications of "Checking"
This scenario combines setup, a posted ACH file, an endpoint request, and an assertion that returned entries have the Checking application. section 8.8.3
Feature files can support more than a single assertion. A scenario for batch entries first prepares a clean database and posts a file, then requests entries and checks that every returned application is Checking. That behavior drives changes across the response model, query, API, and interface, while preserving a concrete statement of the requested outcome. section 8.8.3
