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.
Official plugins
Section titled “Official plugins”| 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 |
Install
Section titled “Install”bddkit plugin install s3bddkit plugin listbddkit plugin install downloads a release, checks it and records it in a lock file. update, remove, show and list manage the same lock file.
Declare an instance
Section titled “Declare an instance”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:9000default_s3: backupsSelect an instance in a scenario the way you select an API or a connection:
Given I use "backups" s3The 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.
Where plugins are kept
Section titled “Where plugins are kept”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.
Writing a plugin
Section titled “Writing a plugin”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.