Skip to content

Plugins

bddkit ships with three resource kinds built in: HTTP APIs, databases and SRP logins. Everything else is a plugin: a shared library that bddkit loads at startup and that brings its own steps. A browser, a phone app or an S3 bucket is declared in the config the same way as an API, and its steps read like any other step.

Plugin What it drives Repository
browser a real browser through WebDriver bddkit/bddkit-browser
appium native Android and Windows apps through Appium bddkit/bddkit-appium
exec local commands and background processes, and their output bddkit/bddkit-exec
s3 S3-compatible object storage (AWS S3, MinIO and others) bddkit/bddkit-s3
Terminal window
bddkit plugin install s3
bddkit plugin list

bddkit plugin install downloads a release, checks it and records it in a lock file. update, remove, show and list manage the same lock file.

Any key under resources: other than api, db and srp is a plugin group. For example, an S3 group:

resources:
s3:
backups:
bucket: acme-backups
endpoint: http://minio:9000
default_s3: backups

Select an instance in a scenario the way you select an API or a connection:

Given I use "backups" s3

The selection resets to the default at every scenario boundary. With one instance in a group, its default is inferred; with several, the default must be named.

Installed plugins are machine state, not part of the test suite. bddkit reads them from a chain of .bddkit/ directories: a shared one for the machine, a user one, and a project one next to the config. Each directory has a plugins.yaml (commit it) and a plugins.local.yaml (usually gitignored). A later entry replaces an earlier one with the same plugin name.

Installing into the project layer vendors the plugin into the repository on purpose, for suites that carry their own build.

The plugin contract is a C ABI over JSON strings, so a plugin can be written in any language that can produce a shared library. See Plugin authoring in the bddkit repository.