Configuration Files

Typing the same options on every run gets old quickly. Behave reads an INI-style configuration file so the stable parts of a run (paths, tags, formatters) live in version control while ad-hoc overrides stay on the command line.

Where Behave Looks

From the directory you run behave in, the runner searches for behave.ini, then behave.cfg, then pytest.ini, and finally setup.cfg (all must contain a [behave] section). The first file found wins, so keep exactly one configuration file per project to avoid surprises.

A Typical behave.ini

[behave]
paths = features
tags = not @wip
format = pretty
# output = reports
# show = True
# dry_run = False
# no_capture = False

Every key maps to a command-line option in its long form: paths to --paths, tags to --tags, format to --format, output to --output, and so on. Boolean keys use INI booleans (True/False, yes/no).

Command Line Wins

Options given on the command line override the file. That split is exactly what you want in practice: the file defines the team default, and a developer or CI job can still run behave -t @smoke -f junit -o reports without editing anything.

# file says tags = not @wip; this run tightens it further
behave -t "@smoke and not @flaky"

One Config per Environment

If test and staging runs need different formatters or tag filters, keep two small files (behave.ini and behave.staging.ini) and copy the right one into place before the run, or drive the differences entirely with command-line arguments. Avoid editing the shared file per environment.

Summary

Put the stable runner options in a [behave] section of behave.ini; the command line still overrides everything for ad-hoc runs. One configuration file per project keeps behavior predictable.