liveBook · Manning

Cucumber

As explained in BDD in Action, Second Edition

Cucumber is a tool that executes behavior specifications written in a human-readable, structured format as automated tests.

A team may agree that commuters should see the next trains to their destination, yet still disagree about which departures qualify. Cucumber lets the team record a concrete acceptance criterion as a structured scenario, then run it as an automated test. Its business-language format helps product owners and testers review what the test claims to verify. section 3.5 section 3.5.2

Listing 3.1 An acceptance criteria expressed in Cucumber
Feature: Show next departing trains
 
  As a commuter traveling between two stations on the same line
  I want to know what time the next trains for my destination will leave
  So that I can spend less time waiting at the station
  Scenario: Next train going to the requested destination on the same line
    Given the T1 train to Chatswood leaves Hornsby at 8:02, 8:15, 8:21
    When Travis wants to travel from Hornsby to Chatswood at 8:00
    Then he should be told about the trains at: 8:02, 8:15

The departing-trains feature shows the division between structural keywords—Feature, Scenario, Given, When, and Then—and the business-specific details that make the expected result precise. section 3.5.2

Scenarios live in .feature files, typically grouped by capability. A feature file can be run before its steps have implementation code: the run fails, but a Serenity BDD report can show the scenario awaiting implementation. Step definitions, also called glue code, connect the written steps to test actions. section 3.5.2 section 8.2.2

Keep specifications and their implementation easy to find:

  • In a Java project, a common location is src/test/resources/features; a test runner executes the feature files, while Java step definitions live under src/test/java. section 8.2.2
  • In a TypeScript project using Cucumber JS, feature files commonly sit under features, with step definitions and support code in subfolders. section 8.2.3

Keep the business outcome visible

A sign-up feature can express success in two high-level steps: sign up with valid details, then confirm sign-in works. A separate duplicate-email scenario states the expected error and password-reset option. Cucumber.js step definitions can map such concise steps to the underlying activities. section 14.3

How BDD in Action, Second Edition covers it

How deep it goes
Explains feature-file syntax, pending runs, project organization, and the role of step definitions without detailing a complete test implementation.
Examples
Illustrates a departing-trains criterion and sign-up scenarios for valid details and a duplicate email address.
What it assumes
Assumes a concrete acceptance criterion and introduces the feature-file structure needed to record it.
What you can do after
Apply it via Cucumber feature files and step definitions to turn agreed behavior into automated acceptance tests.
How it connects
Connects BDD, Gherkin, executable specifications, automated acceptance testing, and living documentation.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of BDD in Action, Second Edition. The section links point to the parts of the book it draws on.