Testland
Browse all skills & agents

cucumber-testing

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.

Install with skills.sh (any agent)

npx skills add testland/qa --skill cucumber-testing
View source

cucumber-testing

Overview

Per cucumber-install (opens in new window):

"Cucumber is available for most mainstream programming languages."

Cucumber implementations split into tiers (cucumber-install (opens in new window)):

  • 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.

When to use

  • The team uses BDD with Gherkin features.
  • Cross-stakeholder collaboration is the value (Gherkin scenarios read by non-engineers).
  • Acceptance criteria authored as Gherkin scenarios per acceptance-criteria-extractor (in the qa-shift-left plugin).

If only engineers will read the tests, BDD's collaboration value is wasted - plain xUnit-style tests are simpler.

Step 1 - Install (Cucumber-JVM)

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.

Step 2 - Install (Cucumber-JS)

npm install --save-dev @cucumber/cucumber

Step 3 - Install (Cucumber-Ruby)

gem install cucumber
# Or in Gemfile:
group :test do
  gem 'cucumber-ruby'
end

Step 4 - Author a Feature

# 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      |

Step 5 - Write step definitions

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.

Step 6 - Run

JVM (via Maven):

mvn test
# Or specific feature:
mvn test -Dcucumber.features=features/cart.feature

JS:

npx cucumber-js features/

Ruby:

cucumber features/

Step 7 - Reporting

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.

Step 8 - Tags + filtering

@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-patterns

Anti-patternWhy it failsFix
Imperative steps ("I click button id=#submit")Couples to implementation; scenarios become fragile.Declarative steps ("I submit the form").
100 unique step definitionsDrift; inconsistency.Step library curation (see bdd-step-library-curator).
BDD without business stakeholder involvementDefeats the point; expensive xUnit tests.If non-engineers don't read the features, switch to plain unit tests.
Mixing Cucumber + plain JUnit assertionsTwo test runners; double maintenance.Cucumber's runner only; plain JUnit for non-BDD tests in separate suite.
Skipping Background for shared setupRepeated Given lines clutter scenarios.Background block (Step 4 example).

Limitations

  • Step ambiguity. Two step definitions matching the same Gherkin line cause runtime errors; the framework reports ambiguous steps but only at runtime.
  • Per-language quirks. Cucumber-JVM's regex syntax differs from Cucumber-JS's; copy-paste between languages doesn't work.
  • Performance. BDD adds runner overhead vs plain xUnit; acceptable for <500-test suites, slow beyond.
  • Step-definition discoverability. Without IDE plugin, finding the implementation behind a Gherkin line is manual grep.

References

  • ci (opens in new window) - Cucumber installation: official + semi-official + unofficial implementation tiers; recommendation to match production language.
  • behave-testing - Python sibling.
  • reqnroll-testing - .NET sibling.
  • bdd-step-library-curator - addresses step proliferation.
  • acceptance-criteria-extractor (in the qa-shift-left plugin) - upstream skill that generates Gherkin from stories.

Cucumber step definitions and reporting

View source (opens in new window)

Cucumber step definitions and reporting

Full step-definition and JUnit XML reporting examples for cucumber-testing (opens in new window) (Steps 5 and 7). The Gherkin feature they bind to is in Step 4 of the SKILL.md.

Step definitions - JVM (Java)

import io.cucumber.java.en.*;

public class CheckoutSteps {

    private Cart cart;
    private CheckoutPage page;

    @Given("a logged-in user with email confirmed")
    public void a_logged_in_user() {
        TestUser user = TestUsers.loggedInWithEmailConfirmed();
        page = new CheckoutPage().loginAs(user);
    }

    @Given("the cart contains {int} of {string} at ${double}")
    public void the_cart_contains(int qty, String sku, double price) {
        cart = new Cart();
        cart.addItem(new Item(sku, qty, price));
        page.setCart(cart);
    }

    @When("I enter {string} in the promo input")
    public void i_enter(String code) {
        page.enterPromo(code);
    }

    @When("I click {string}")
    public void i_click(String label) {
        page.click(label);
    }

    @Then("the subtotal updates to ${double}")
    public void the_subtotal_updates(double expected) {
        assertEquals(expected, page.getSubtotal(), 0.01);
    }
}

Step definitions - JS

const { Given, When, Then } = require('@cucumber/cucumber');

Given('a logged-in user with email confirmed', function() {
  this.user = createLoggedInUser();
  this.page = new CheckoutPage(this.user);
});

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);
});

Reporting

Cucumber outputs to multiple formats; JUnit XML is the CI-canonical one.

JVM (in cucumber.properties):

cucumber.plugin=pretty,html:target/cucumber-report.html,junit:target/cucumber-report.xml

JS (CLI):

npx cucumber-js features/ \
  --format html:reports/cucumber.html \
  --format junit:reports/cucumber.xml

The JUnit XML feeds junit-xml-analysis (in the qa-test-reporting plugin).

Related skills

acceptance-test-from-criteria

ATDD (Acceptance Test-Driven Development) workflow that generates @AC-N-tagged Gherkin scenarios from a signed-off acceptance-criteria list, scaffolds NotImplementedError step stubs, and produces an AC-to-test traceability table, all before implementation begins, in the team's BDD framework (Cucumber / Behave / Reqnroll). Use when devs are gated on green acceptance tests and failures must map back to a specific criterion. For story-narrative-to-Gherkin without prior ACs, use gherkin-from-stories. For BDD scenario authoring without the ATDD test-first gate, use a general BDD scenario-authoring workflow.

bdd-overview

Teaches behaviour-driven development end to end for a newcomer: what BDD is and how discovery, formulation and automation fit together; a decision table that picks the runner from the project's language and build files (Cucumber-JVM, Cucumber-JS, Cucumber-Ruby, Behave for Python, Reqnroll for .NET, and why SpecFlow is end-of-life); install and first-run commands for each; the declarative-versus-imperative Gherkin discipline with a worked bad-versus-good pair; Background, Scenario Outline and domain-organised step libraries; the traps that make BDD collapse into an expensive UI-automation wrapper; and an honest account of when BDD is not worth adopting. Use when a team is adopting BDD, choosing a Gherkin runner, or a *.feature file needs writing and nobody has settled the conventions.

bdd-step-library-curator

Keeps a BDD step-definition library DRY across a Cucumber / Behave / Reqnroll project - inventories every step definition, detects duplicates (different patterns matching the same intent), recommends canonical consolidations, reorganizes steps by domain, and publishes a step-library README the team greps for "is there already a step for X?" before authoring new ones. Use when a BDD project's step count grows past ~50, on a quarterly step-library review, or when a new engineer cannot find an existing step and is about to write a duplicate.

behave-testing

Configures Behave for Python BDD scenarios - `pip install behave`, authors `.feature` files in Gherkin, writes step implementations in `features/steps/*.py`, configures via `environment.py` for setup/teardown hooks, organizes via tags, runs via `behave`. Use for Python codebases that want Cucumber-family BDD without Cucumber-Ruby / Cucumber-JS.

gherkin-from-stories

Build-an-X workflow that converts user stories into Gherkin scenarios - extracts the actor / capability / value triple from "As a … I want … so that …", maps acceptance criteria to Scenario blocks, identifies parameterizable axes for Scenario Outlines, and emits a Feature file ready for `bdd-step-library-curator`-curated step definitions. Starts from the story itself rather than from an already-extracted acceptance-criteria list; this skill operates at the user-story layer and produces Gherkin directly. Emits Gherkin only: no step definition stubs and no runner detection. For a full runnable artifact (Feature file plus scaffolded step definitions), follow this skill with step-definition scaffolding for the detected runner. Use when a PM hands over a user story or a backlog of stories and the team's first test artifact is the `.feature` file rather than a separate AC doc.

living-documentation-publisher

Converts passing Cucumber JSON output into stakeholder-facing living documentation: generates HTML reports via multiple-cucumber-html-reporter (Node) or Serenity BDD aggregate (JVM), applies Gherkin tags to drive report sections, and publishes to GitHub/GitLab Pages in CI. Use when BDD scenarios are in use and the team needs an always-current, non-test-engineer-readable document showing which acceptance criteria pass.

manual-step-to-gherkin

Translates an existing manual test step (table row, prose bullet, TestRail/Qase exported step) into a declarative Gherkin Given/When/Then step phrased in business language - strips UI mechanics ("clicks the button", "types in the field"), elevates the user intent ("signs in", "adds the product"), and aligns vocabulary with the project's existing step library. The input is an already-written manual step - not a user story and not an acceptance-criteria list. Use when a team is migrating manual test scripts to BDD, or when a manual tester is handing a script off to an automation engineer.

reqnroll-testing

Configures Reqnroll (the canonical .NET BDD framework) - install via `dotnet add package Reqnroll`, author `.feature` files in Gherkin, write step bindings as `[Given/When/Then]`-decorated methods in any C# class, runs via `dotnet test`. Reqnroll is the SpecFlow successor (originated as a community port off the SpecFlow codebase); new .NET BDD work targets Reqnroll. Use for .NET projects starting BDD or migrating from SpecFlow.

specflow-testing

Maintains SpecFlow tests on existing .NET projects - authors Gherkin `.feature` files, writes C# `[Binding]` step definitions, runs them via xUnit/NUnit/MsTest, and migrates a project to Reqnroll. SpecFlow is the legacy .NET BDD framework and Reqnroll is its maintained fork. Use only for existing SpecFlow projects, especially mid-migration; new .NET BDD projects use `reqnroll-testing` instead.