Cucumber

Visit Website

Introduction

Cucumber runs behaviour-driven scenarios written in Gherkin. A .feature file holds Feature, Scenario, Given, When, and Then lines in plain language. Step definitions, written in a programming language, match those lines with regular expressions or Cucumber expressions and perform the actual work: call an API, drive a browser, or talk to a domain object. The runner executes the scenarios and reports which steps passed.

This entry is Cucumber Open, the open-source tool. The JavaScript, Java, and Ruby implementations live in the Cucumber GitHub organization; cucumber/cucumber is the coordination repository. CucumberStudio, already in this directory, is SmartBear’s separate BDD collaboration product. Installing Cucumber does not give you CucumberStudio, and the Studio page does not document the open-source runners.

Features

1. Gherkin: Keywords (Given, When, Then, And, But), Scenario Outline with an Examples table, Background, and tags such as @wip.
2. Language implementations: cucumber-js (JavaScript and TypeScript), Cucumber-JVM (Java and other JVM languages), and cucumber-ruby are the main runners. Docs and support levels differ by repo.
3. Step definitions: A step is a function or method bound to a pattern. Parameters are captured from the sentence ({string}, {int}) instead of parsed by hand.
4. Hooks: Before, After, and tagged hooks set up a browser or a database for the scenarios that need them.
5. Tags for selection: @smoke and --tags choose which scenarios a CI job runs.
6. Data tables and doc strings: A step can receive a table or a multiline string as an argument.
7. Reports: Formatters emit progress, JSON, JUnit XML, and HTML. Allure and other reporters plug in at this layer.
8. Living documentation only if the steps stay honest: The feature file documents behaviour when the step text still matches what the code does.

Pros

1. Scenarios are readable outside the test code: A product owner can review a feature file without reading Selenium calls.
2. The same Gherkin runs on several stacks: A Java API suite and a JavaScript UI suite can share a style, even though they cannot share step-definition functions.
3. Outlines keep tables out of the code: Example rows are data. The step body stays one path.
4. Tags split CI: Smoke scenarios on every commit, the full file on a nightly job, without a second runner.
5. Free: The open-source runners are free to use in private projects. cucumber-js is MIT-licensed. Check the license file of the implementation you install; they are not one artifact.

Cons

1. Gherkin has a cost: Low-level unit tests written as Given/When/Then are harder to navigate than a normal JUnit or pytest function. Cucumber pays off for acceptance scenarios, not for every assert.
2. Step drift: The sentence says “the user is logged in” and the step quietly seeds an admin flag. The feature file then documents the wrong system. Reviews have to include the step body.
3. Undefined and ambiguous steps fail at runtime: A typo in a feature file is a missing step, discovered when that scenario runs, not by the compiler of the application.
4. Three codebases: cucumber-js, Cucumber-JVM, and cucumber-ruby release on their own schedules. A blog post about one does not apply to the others.
5. CucumberStudio is easy to confuse with this: Buying or configuring Studio does not upgrade the open-source runner, and this runner does not include Studio’s test-management UI.

Usage and Links (Example)

JavaScript:

npm install --save-dev @cucumber/cucumber
npx cucumber-js

Feature: Sign in
  Scenario: Valid email reaches the inbox
    Given I am on the sign-in page
    When I sign in as "[email protected]"
    Then I see "Inbox"

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

Given("I am on the sign-in page", async function () {
  await this.page.goto("/signin");
});

When("I sign in as {string}", async function (email) {
  await this.page.getByLabel("Email").fill(email);
  await this.page.getByRole("button", { name: "Continue" }).click();
});

Then("I see {string}", async function (text) {
  await this.page.getByText(text).waitFor();
});

Put features under features/ and steps under features/step_definitions/. The JVM equivalent is the cucumber-java dependency and a JUnit Platform suite. Ruby uses the cucumber gem.

Resources:

• Cucumber website
• Gherkin reference
• GitHub: cucumber/cucumber
• CucumberStudio (separate commercial product in this directory)

Pricing

1. Cucumber Open: Free. Use the language-specific package (@cucumber/cucumber, io.cucumber:cucumber-java, or the Ruby gem). There is no seat fee for the runner.
2. CucumberStudio: A paid BDD collaboration product, documented on its own directory page. It is not included with the open-source gem or npm package.
3. SmartBear commercial support: Optional and separate from running the OSS tool in CI.

Recommended for?

1. Acceptance tests that product and engineering will both read, especially flows with several examples.
2. API or UI suites that already have a programmer-owned step layer and a small Gherkin vocabulary.
3. Teams standardizing on Gherkin across Java and JavaScript services, with separate step code per repo.
4. Not for unit tests. Those stay in JUnit, pytest, Jest, or Vitest.

Conclusion

Cucumber Open is the Gherkin runner. Use it when the feature file is a real shared spec and the steps stay thin and honest. Keep CucumberStudio as the other directory entry it already is. If nobody outside the test code reads the features, drop the extra layer and call the automation framework directly.