qa-bdd
Behavior-driven development with Cucumber, Behave and Reqnroll: Gherkin from user stories and acceptance criteria, step libraries, and living docs. Converts stories, acceptance-criteria lists, manual steps or raw specs into Gherkin, keeps step definitions DRY, and covers SpecFlow-to-Reqnroll migration. Agents (bdd-scenario-author, gherkin-style-reviewer) write scenarios with step stubs and flag imperative steps and technical leakage.
/plugin install qa-bdd@testland-qaFirst time? Add the marketplace with /plugin marketplace add testland/qa
- Category
- Functional testing
- Version
v1.9.5- Contents
- 6 skills · 2 agents
Skills6
bdd-step-library-curatorUse when a Cucumber, Behave or Reqnroll project has grown past ~50 step definitions, before writing a step that may already exist, or when new .feature files need a duplicate check.skillbehave-testingUse when a Python project wants BDD scenarios with Behave: Gherkin .feature files, step implementations in features/steps, environment.py hooks, tags and behave runs in CI.skillcucumber-testingConfigures Cucumber for BDD scenarios - Cucumber-JVM (Java/Kotlin via JUnit 5), Cucumber-JS (Node), Cucumber-Ruby.skillgherkin-from-storiesUse whenever user stories, acceptance criteria, manual test steps or a spec section need to become Gherkin .feature files.skillliving-documentation-publisherUse when BDD scenarios pass in CI and stakeholders need an always-current, readable report of which acceptance criteria pass.skillreqnroll-testingUse when a .NET project starts BDD, migrates from SpecFlow (end-of-life 2024-12-31) or maintains a legacy SpecFlow suite.skill
Agents2
bdd-scenario-authorAction-taking agent that authors Gherkin scenarios and scaffolds step definitions end-to-end - accepts a user story or acceptance criteria list, invokes gherkin-from-stories (the authoring umbrella covering story, AC-list, manual-step, and raw-spec inputs) to produce a Feature file, detects the project's BDD runner (Cucumber-JVM, Cucumber-JS, Cucumber-Ruby, Behave, Reqnroll, or SpecFlow), and emits idiomatic step definition stubs wired to that runner.agentgherkin-style-reviewerAdversarial reviewer for Gherkin Feature files - flags imperative steps ("click button #foo"), technical leakage (DB names / API URLs / CSS selectors in steps), "And And And" chains (excessive coordination), missing Background extraction (repeated Givens across scenarios), and Then-without-observable-outcome (vague assertions).agent
About qa-bdd
Behavior-driven development pipelines: per-language Cucumber-family runners (Cucumber-JVM/JS/Ruby, Behave Python, Reqnroll .NET - replaces the end-of-life SpecFlow), a requirements-to-Gherkin authoring umbrella, step-library curation with scenario coverage mapping, Gherkin style review, and living documentation.
Start here: picking a runner
BDD runs as three repeating practices - Discovery (talk through concrete examples), Formulation (document them as Gherkin), Automation (implement each example test-first). Runner choice is almost entirely determined by language and build system, because step definitions are written in that language:
| What you find in the repo | Runner | Skill |
|---|---|---|
pom.xml / build.gradle (Java, Kotlin), package.json (Node), or Gemfile (Ruby) | Cucumber-JVM / Cucumber-JS / Cucumber-Ruby | cucumber-testing |
requirements.txt / pyproject.toml (Python) | Behave | behave-testing |
*.csproj / *.sln (.NET) - including repos still on the end-of-life SpecFlow | Reqnroll (SpecFlow's maintained successor) | reqnroll-testing |
| No stakeholder outside engineering will ever read the feature files | None - write tests directly in your test framework | see the "when BDD is not worth it" test in cucumber-testing's references/runner-selection.md |
The full decision table with citations, per-runner first-run commands, and the SpecFlow end-of-life story live in cucumber-testing's runner-selection reference (opens in new window).