Configures Cucumber for BDD scenarios - Cucumber-JVM (Java/Kotlin via JUnit 5), Cucumber-JS (Node), Cucumber-Ruby. Authors `.feature` files in Gherkin, writes step definitions in the host language, runs via the framework's runner, integrates with JUnit XML reporting. Use when the user mentions Cucumber, Gherkin, `.feature` files, or behavior-driven (BDD) tests in Java, Kotlin, JavaScript, or Ruby, as the canonical wrapper for any of the three official implementations.
91%
Does it follow best practices?
Impact
91%
1.03xAverage score across 10 eval scenarios
Low
Low-risk findings worth noting
The canonical home for this skill is testland/cucumber-testing
Per cucumber-install:
"Cucumber is available for most mainstream programming languages."
Cucumber implementations split into tiers (cucumber-install):
- Official: Hosted under the main Cucumber organization (JavaScript, Java, Ruby, Android, Kotlin, Scala, C++)
- Semi-official: Developed elsewhere but use Cucumber components (PHP's Behat, Python's Behave, .NET's Reqnroll)
This skill covers the three most-used official implementations:
Cucumber-JVM (Java + Kotlin), Cucumber-JS (Node), and
Cucumber-Ruby. For Python, see
behave-testing. For .NET, see
reqnroll-testing.
gherkin-from-stories.If only engineers will read the tests, BDD's collaboration value is wasted - plain xUnit-style tests are simpler. Not sure which runner fits the repo, or whether BDD is worth adopting at all? See references/runner-selection.md - the runner decision table, per-runner first-run commands, the SpecFlow end-of-life note, and the "when BDD is not worth it" test.
Maven:
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-java</artifactId>
<version>7.20.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit-platform-engine</artifactId>
<version>7.20.0</version>
<scope>test</scope>
</dependency>For Kotlin: replace cucumber-java with cucumber-kotlin.
npm install --save-dev @cucumber/cucumbergem install cucumber
# Or in Gemfile:
group :test do
gem 'cucumber-ruby'
end# features/cart.feature
Feature: Apply promo code at checkout
Background:
Given a logged-in user with email confirmed
And the cart contains 1 of "BOOK-001" at $24.99
Scenario: Apply valid promo
When I enter "WELCOME10" in the promo input
And I click "Apply"
Then the subtotal updates to $22.49
And a confirmation toast appears
Scenario Outline: Promo validation rejects bad codes
When I enter "<code>" in the promo input
And I click "Apply"
Then an error appears: "<error>"
Examples:
| code | error |
| EXPIRED50 | This code has expired |
| NOTREAL | Code not found |
| "" (empty) | Please enter a code |Bind each Gherkin line to a method with a {cucumber-expression} capture.
Minimal JS example:
const { Given, When, Then } = require('@cucumber/cucumber');
Given('a logged-in user with email confirmed', function() {
this.page = new CheckoutPage(createLoggedInUser());
});
When('I enter {string} in the promo input', function(code) {
this.page.enterPromo(code);
});
Then('the subtotal updates to ${float}', function(expected) {
assert.equal(this.page.getSubtotal(), expected);
});Full Java (Cucumber-JVM) and JS step definitions, plus the JUnit XML reporting config, are in references/step-definitions-and-reporting.md.
JVM (via Maven):
mvn test
# Or specific feature:
mvn test -Dcucumber.features=features/cart.featureJS:
npx cucumber-js features/Ruby:
cucumber features/Cucumber outputs multiple formats; JUnit XML is the CI-canonical one and feeds
junit-xml-analysis (in the qa-test-reporting plugin). The JVM
(cucumber.properties) and JS (CLI) reporting config is in
references/step-definitions-and-reporting.md.
@regression @critical
Scenario: Apply valid promo
...# Run only critical tests
npx cucumber-js features/ --tags '@critical'
# Skip @wip
npx cucumber-js features/ --tags 'not @wip'| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Imperative steps ("I click button id=#submit") | Couples to implementation; scenarios become fragile. | Declarative steps ("I submit the form"). |
| 100 unique step definitions | Drift; inconsistency. | Step library curation (see bdd-step-library-curator). |
| BDD without business stakeholder involvement | Defeats the point; expensive xUnit tests. | If non-engineers don't read the features, switch to plain unit tests. |
| Mixing Cucumber + plain JUnit assertions | Two test runners; double maintenance. | Cucumber's runner only; plain JUnit for non-BDD tests in separate suite. |
Skipping Background for shared setup | Repeated Given lines clutter scenarios. | Background block (Step 4 example). |
behave-testing - Python sibling.reqnroll-testing - .NET sibling.bdd-step-library-curator - addresses step proliferation.gherkin-from-stories - upstream skill that generates Gherkin from stories, AC lists, manual steps, and raw specs.testland/qa
aa16752
Canonical home
since Jul 23, 2026
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.