| Role ("amigo") | Primary concerns | Features provided by rstest‑bdd |
|---|---|---|
| Business analyst/product owner | Writing and reviewing business-readable specifications; ensuring that acceptance criteria are expressed clearly. | Gherkin .feature files are plain text and start with a Feature declaration; each Scenario describes a single behaviour. Steps are written using keywords Given, When, and Then (syntax), producing living documentation that can be read by non-technical stakeholders. |
| Developer | Implementing step definitions in Rust and wiring them to the business specifications; using existing fixtures for setup/teardown. | Attribute macros #[given], #[when] and #[then] register step functions and their pattern strings in a global step registry. A #[scenario] macro reads a feature file at compile time and generates a test that drives the registered steps. Fixtures whose parameter names match are injected automatically; use #[from(name)] only when a parameter name differs from the fixture. |
| Tester/QA | Executing behaviour tests, ensuring correct sequencing of steps and verifying outcomes observable by the user. | Scenarios are executed via the standard cargo test runner; test functions annotated with #[scenario] run each step in order and panic if a step is missing. Assertions belong in Then steps; guidelines discourage inspecting internal state and encourage verifying observable outcomes. Testers can use cargo test filters and parallelism because the generated tests are ordinary Rust tests. |
The following sections expand on these responsibilities and show how to use the current API effectively.