Config keys

This page is written by hand. The keys each resource takes are generated: see Resource fields.

Where the config is found

--config <path> names the file. Without it, bddkit uses $BDDKIT_CONFIG, and then bddkit.yaml or bddkit.yml in the working directory. If both exist, bddkit refuses to run and names both. It never looks in parent directories: paths and macro_paths resolve against the working directory, so a config found in a parent would select the wrong feature files.

Example

concurrency: 8              # files in flight; a file is one task
macro_paths: [macros/]
paths: [features/]

resources:
  api:
    review:
      base_url: http://review.local
      default_headers: { X-Client: bddkit }
  db:
    default:
      dsn: postgres://${DB_USER}:${DB_PASS}@db:5432/review
      search_path: [app, public]

options:
  polling: { timeout_secs: 5, interval_ms: 100 }

evidence: [marked, failures]

Top-level keys

Key	What it sets
paths	feature files or directories to run, relative to the working directory
macro_paths	YAML files or directories that declare domain steps
concurrency	files run at the same time; default 8. Set 1 for a suite that is not yet parallel-safe
resources	the named resources, by kind: api, db, srp, and any group a plugin serves
default_api, default_db, default_srp, default_<group>	the resource a scenario starts on. Inferred when a kind has exactly one; must be named when it has several
options	defaults for every resource. options.polling sets how long and how often an eventual assertion retries
evidence	the default evidence sources when a run has --events and no --evidence

Resources

Each kind takes its own keys. Resource fields lists them, generated from the binary. Any key under resources other than api, db and srp is a plugin group; see Plugins.

A resource’s options override the top-level options for that resource only.

Expansion

${VAR} values are expanded when the config is read, with the same syntax as docker compose: ${VAR:-default}, ${VAR:?message} and ${VAR:+value} work. The variables come from the real environment and from a .env file stack next to the config, read in this order, later files winning: .env, .env.local, .env.<APP_ENV>, .env.<APP_ENV>.local. APP_ENV is taken from --env, then from the environment, then from .env, and defaults to dev.

Concurrency and ordering

Feature files run in parallel. Two files that contend for the same data go into one @serial(name) chain and run one after another. @priority(N) moves a file up the queue. Variables live for the whole feature file; request state and the current connection reset for each scenario.