Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Cucumber (software).
Nothing was collected or created yet.
Cucumber (software)
View on Wikipediafrom Wikipedia
| Cucumber | |
|---|---|
| Developers | Aslak Hellesøy,[1] Joseph Wilk,[2] Matt Wynne,[3] Gregory Hnatiuk,[4] Mike Sassak[5] |
| Stable release | 12.5.0[6] 
/ 26 December 2025 |
| Written in | Ruby |
| Operating system | Cross-platform |
| Type | Behavior driven development framework / Test tool |
| License | MIT License |
| Website | cucumber |
| Repository | |
Cucumber is a software tool that supports behavior-driven development (BDD).[7][8][9][10][11][12] Central to the Cucumber BDD approach is its ordinary language parser called Gherkin. It allows expected software behaviors to be specified in a logical language that customers can understand. As such, Cucumber allows the execution of feature documentation written in business-facing text.[13][7][8] It is often used for testing other software.[14] It runs automated acceptance tests written in a behavior-driven development (BDD) style.[15]
Cucumber was originally written in the Ruby programming language[7][16][8] and was originally used exclusively for Ruby testing as a complement to the RSpec BDD framework. Cucumber now supports a variety of different programming languages through various implementations, including Java[17][8] and JavaScript.[18][19] There is a port of Cucumber to .NET called SpecFlow,[20][21][22] now superseded by Reqnroll.[23]
Gherkin language
[edit]Gherkin is the language that Cucumber uses to define test cases. It is designed to be non-technical and human readable, and collectively describes use cases relating to a software system.[7][8][24][25] The purpose behind Gherkin's syntax is to promote behavior-driven development practices across an entire development team, including business analysts and managers. It seeks to enforce firm, unambiguous requirements starting in the initial phases of requirements definition by business management and in other stages of the development lifecycle.
In addition to providing a script for automated testing, Gherkin's natural language syntax is designed to provide simple documentation of the code under test.[25] Gherkin currently supports keywords in dozens of languages.[25][26][7][8]
Syntax
[edit]Syntax is centered around a line-oriented design, similar to that of Python. The structure of a file is defined using whitespace and other control characters.[25] Lines starting with # are considered comments, and can be placed anywhere in a file.[25] Instructions are any non-empty and non-comment line. They consist of a recognized Gherkin keyword followed by a string.[27]
All Gherkin files have the .feature file extension. They contain a single Feature definition for the system under test and are an executable test script.[27]
Here is an example of the syntax:[28]
Feature: Guess the word
# The first example has two steps
Scenario: Maker starts a game
When the Maker starts a game
Then the Maker waits for a Breaker to join
# The second example has three steps
Scenario: Breaker joins a game
Given the Maker has started a game with the word "silky"
When the Breaker joins the Maker's game
Then the Breaker must guess a word with 5 characters
Command line
[edit]Cucumber comes with a built-in command line interface that covers a comprehensive list of instructions. Like most command line tools, cucumber provides the --help option that provides a summary of arguments the command accepts.[29]
$ cucumber --help
-r, --require LIBRARY|DIR Require files before executing the features.
--i18n LANG List keywords for in a particular language.
Run with "--i18n help" to see all languages.
-f, --format FORMAT How to format features (Default: pretty).
-o, --out [FILE|DIR] Write output to a file/directory instead of
...
Cucumber command line can be used to quickly run defined tests. It also supports running a subset of scenarios by filtering tags.
$ cucumber --tags @tag-name
The above command helps in executing only those scenarios that have the specified @tag-name.[29] Arguments can be provided as a logical OR or AND operation of tags. Apart from tags, scenarios can be filtered on scenario names.[29]
$ cucumber --name logout
The above command will run only those scenarios that contain the word 'logout'.
It is also useful to be able to know what went wrong when a test fails. Cucumber makes it easy to catch bugs in the code with the --backtrace option.[29]
References
[edit]- ^ "Aslak Hellesøy". Aslakhellesoy.com. Retrieved 2012-01-24.
- ^ "Joseph Wilk | on AI, The Web, Usability, Testing & Software process". Blog.josephwilk.net. Retrieved 2012-01-24.
- ^ "Tea-Driven Development". Blog.mattwynne.net. Retrieved 2012-01-24.
- ^ "ghnatiuk's Profile". GitHub. Retrieved 2012-01-24.
- ^ "msassak's Profile". GitHub. Retrieved 2012-01-24.
- ^ "Release 12.5.0". 26 December 2025. Retrieved 28 December 2025.
- ^ a b c d e "The Pragmatic Bookshelf | The Cucumber Book". Pragprog.com. Archived from the original on 2012-01-21. Retrieved 2012-01-24.
- ^ a b c d e f Rose, Seb; Wynne, Matt; Hellesøy, Aslak (15 February 2015). The Pragmatic Bookshelf | The Cucumber For Java Book. Pragprog.com. Retrieved 2019-04-28.
- ^ "What is Cucumber?". cucumber. Retrieved 2019-06-08.
- ^ Aslak Hellesøy. "The world's most misunderstood collaboration tool". cucumber.
- ^ Nagy, Gáspár; Rose, Seb (2017-03-07). The BDD Books - Discovery. Leanpub. ISBN 978-1983591259.
- ^ Rose, Seb; Nagy, Gáspár (2021-04-27). The BDD Books – Formulation. Leanpub. ISBN 979-8723395015.
- ^ Fox, Armando; Patterson, David (2016). Engineering Software as a Service. Strawberry Canyon. pp. 218–255. ISBN 978-0-9848812-4-6.
- ^ "Automated testing with Selenium and Cucumber". www.ibm.com. 2013-08-06. Retrieved 2017-02-09.
- ^ Soeken, Mathias; Wille, Robert; Drechsler, Rolf (2012-05-29). Furia, Carlo A.; Nanz, Sebastian (eds.). Objects, Models, Components, Patterns. Lecture Notes in Computer Science. Springer Berlin Heidelberg. pp. 269–287. doi:10.1007/978-3-642-30561-0_19. ISBN 9783642305603.
- ^ "The Pragmatic Bookshelf | The RSpec Book". Pragprog.com. 2010-12-02. Archived from the original on 2012-01-21. Retrieved 2012-01-24.
- ^ "Cucumber-jvm". cucumber. Retrieved 2018-03-08.
- ^ "Cucumber-js". cucumber. Retrieved 2018-03-08.
- ^ Naidele Manjunath; Olivier de Meulder (2019-02-01). "No Code? No Problem — Writing Tests in Plain English". Times Open. Retrieved 2019-04-29.
- ^ "Binding Business Requirements to .NET Code". SpecFlow. Retrieved 2019-04-29.
- ^ "SpecFlow". GitHub. Retrieved 2019-04-29.
- ^ Richard Lawrence; Paul Rayner (2018). Behavior-Driven Development with Cucumber. Addison Wesley.
- ^ Nagy, Gáspár (8 February 2024). "From SpecFlow to Reqnroll: Why and How". reqnroll.net. Reqnroll. Retrieved 18 April 2024.
- ^ "cucumber/gherkin". GitHub. Retrieved 2017-02-09.
- ^ a b c d e "Gherkin Syntax". cucumber. Retrieved 2019-07-09.
- ^ "Gherkin Supported Languages". Gherkin. cucumber/cucumber: Cucumber monorepo - building blocks for Cucumber in various languages. Retrieved 2021-03-21 – via GitHub.
- ^ a b "Reference". cucumber. Archived from the original on 2015-10-25. Retrieved 2016-01-17.
- ^ "Gherkin Reference". cucumber. Archived from the original on 2024-01-13. Retrieved 2024-02-11.
- ^ a b c d Wynne, Matt; Hellesoy, Aslak. "The Cucumber Book". SafariBooksOnline. Retrieved 22 January 2016.
External links
[edit]
Cucumber (software)
View on Grokipediafrom Grokipedia
Overview
Purpose and Benefits
Cucumber is an open-source tool designed to support Behavior-Driven Development (BDD) by allowing teams to write executable specifications using plain, business-readable language known as Gherkin.[1][9] This approach enables the creation of automated acceptance tests that serve as living documentation, bridging the communication gap between non-technical stakeholders and developers.[6] BDD extends Test-Driven Development (TDD) by emphasizing collaboration among developers, testers, and business stakeholders to define software behavior through concrete examples, rather than focusing solely on code-level tests.[10][6] It promotes structured conversations in agile environments, such as discovery workshops, to align on requirements and reduce ambiguities early in the development cycle.[6] The primary benefits of Cucumber include enhanced team communication through natural language scenarios that are accessible to all roles, fostering shared understanding and minimizing requirement misunderstandings.[6] It generates evolving living documentation that automatically verifies against the system's behavior, supporting agile methodologies by enabling rapid iterations, quick feedback, and reduced manual regression testing.[6] Additionally, Cucumber facilitates the automation of acceptance criteria, leading to more reliable software delivery with fewer defects.[11] BDD was pioneered by Dan North between 2003 and 2006 as an evolution of agile practices to improve team collaboration and specification clarity, with Cucumber emerging as a key practical implementation tool for executing these principles.[3][12] For instance, teams at the BBC have adopted Cucumber for automating acceptance criteria in their software projects.[13]Key Components
Cucumber's modular architecture consists of several core components that enable the execution of behavior-driven tests. At the foundation are feature files, which store Gherkin-based scenarios describing expected software behavior in plain text format. These files serve as the primary input for the testing process, allowing non-technical stakeholders to define requirements.[14] The Gherkin parser plays a crucial role by translating these plain text feature files into an Abstract Syntax Tree (AST), a structured representation that facilitates further processing and execution. This parser, part of the language-agnostic Cucumber core, tokenizes the input, builds the AST, and compiles it into simplified structures known as Pickles for efficient handling across implementations.[15] Step definitions form another essential component, acting as code mappings that link individual Gherkin steps to executable actions in the application's programming language. These definitions bridge the gap between descriptive scenarios and actual implementation, ensuring that each step triggers the appropriate system behavior during test runs.[16] The runner component orchestrates the overall test execution, loading feature files, matching steps to definitions, and invoking the necessary code. Cucumber distinguishes between its core, which handles parsing and protocol-agnostic logic, and language-specific runners such as Cucumber-JVM for Java, which integrate with the target runtime environment to perform the actual computations.[4] An event-based architecture underpins the interaction among components, where the runner emits events via an internal event bus during parsing and execution phases. These events, standardized through the Cucumber Messages protocol, allow hooks—special functions that intercept events—to perform actions like setup or teardown without altering core flows. Formatters subscribe to these events to generate reports in formats such as HTML or JSON, capturing outcomes like scenario success or failure.[17][18][19] Component interactions follow a sequential pipeline: scenario outlines in feature files are parsed into an AST by the Gherkin parser, steps are matched to definitions by the runner, execution proceeds with event emissions for monitoring and hooking, and finally, formatters process the events to produce reporting outputs. This design ensures loose coupling, with the command-line runner serving as a common entry point for initiating the process.[9][15]History
Origins and Development
Cucumber was created in 2008 by Aslak Hellesøy as a Ruby-based tool designed to support behavior-driven development (BDD) practices, initially serving as a complement to the RSpec framework. Hellesøy developed it to address limitations in RSpec's Story Runner, such as poor error messages and lack of support for step definition snippets, aiming to make automated testing more accessible and collaborative. The tool's core motivation was to bridge communication gaps in agile teams by enabling non-technical stakeholders, like product owners, to author executable specifications in plain language, thereby fostering shared understanding of software behavior.[3][2] The project drew significant influence from Dan North's foundational work on BDD, outlined in his 2006 article "Introducing BDD," which emphasized using natural language to describe behaviors and promote collaboration among developers, testers, and business representatives. Additionally, it built upon earlier BDD tools like JBehave, launched by North in 2003 as a Java-based framework for executable specifications. Cucumber introduced the Gherkin language alongside its launch, allowing scenarios to be written in a structured, human-readable format using keywords like Given, When, and Then.[3][20] The first public release of Cucumber occurred in 2008 under the MIT open-source license, quickly gaining traction within the Ruby ecosystem for its integration with testing tools like RSpec and its emphasis on readable acceptance tests. Early adoption highlighted its utility in agile environments, where teams used it to align technical implementation with business requirements. By around 2010, the project expanded beyond Ruby with the release of Cucumber-JVM, a port for the Java platform that enabled broader use in enterprise settings and JVM-based languages. This period marked the beginning of multi-language support, solidifying Cucumber's role as a cross-platform BDD tool.[2]Major Releases and Milestones
Cucumber-Ruby achieved its first stable release with version 1.0 in July 2011, marking a milestone in providing reliable behavior-driven development (BDD) support for Ruby projects.[21] This version emphasized stability and laid the foundation for broader adoption beyond initial prototypes. Subsequent minor updates in 2011 and 2012 refined core functionality. In 2018, Cucumber-JVM released version 4.0, featuring a major refactor to improve modularity and dependency management, enabling better integration with Java ecosystems like Maven.[22] This update addressed performance bottlenecks in earlier iterations and supported parallel execution enhancements, responding to growing demands in enterprise Java testing. By 2021, Cucumber unified its core across implementations with version 7.0 releases—for Ruby in July and JVM in October—standardizing the Gherkin parser and runtime to simplify maintenance across languages.[23] A significant organizational milestone occurred in June 2019 when Cucumber Ltd., founded in 2013 to provide commercial services and products supporting the open-source project, was acquired by SmartBear, which aimed to enhance resources for open-source maintenance and commercial tools like CucumberStudio.[7] This acquisition initially boosted development but led to community concerns in 2023 over slower updates and layoffs of key contributors, raising fears about the project's sustainability.[24] These issues were addressed in December 2024 when the project returned to full community ownership, revitalizing contributions.[25] Other notable milestones include the maturation of JavaScript support through Cucumber.js, with stable integrations solidifying around 2015 to accommodate Node.js environments. In 2022, version updates included deprecations of legacy options to streamline outputs to modern reporters.[26] As of November 2025, Cucumber remains actively developed under community governance, with recent releases like Ruby v10.1.1 (October 8, 2025) and JVM v7.31.0 (October 28, 2025) focusing on compatibility with cloud platforms such as AWS and Azure, alongside emerging AI-assisted tools for scenario generation in the broader ecosystem.[27][28][29]Gherkin Language
Syntax and Structure
Gherkin feature files, which use the .feature extension, must be encoded in UTF-8 to ensure proper handling of international characters and keywords across supported languages.[30][15] A Gherkin file begins with a single Feature keyword followed by a colon and a descriptive title, establishing the high-level capability or functionality under test.[30] This is optionally preceded by tags, denoted by @ symbols on the line above the Feature, which allow grouping and selective execution of features or scenarios.[30] Below the Feature title, a multi-line description in free-form text can provide context, terminating at the next keyword or structural element.[30] The hierarchical organization includes an optional Background section, which contains shared steps executed before each scenario within the feature, promoting reusability for common preconditions.[30] Following the Background, the file defines one or more Scenario or Scenario Outline blocks. A Scenario represents a single executable test case, while a Scenario Outline supports parameterization through an Examples table for data-driven testing.[30] Each scenario or outline includes a title and optional description, followed by a sequence of steps that form the core executable content.[30] Syntax rules enforce an indentation-based structure using consistent spaces or tabs, recommended at two spaces per level, ensuring parseability without ambiguity.[30] Comments begin with # at the start of a line and are ignored during execution.[30] Data tables, used for passing structured data to steps, are delimited by vertical bars (|) in pipe-separated rows, with support for escaping special characters like newlines (\n), pipes (|), and backslashes (\).[30] Doc strings for multi-line inputs, such as JSON or XML, are enclosed in triple double quotes (""") or triple backticks (```), preserving indentation relative to the step.[30] The parsing process begins with a scanner that reads the feature file line by line, converting content into tokens based on keywords, indentation, and delimiters.[31] These tokens are then fed to a parser, which constructs an Abstract Syntax Tree (AST) representing the document's structure, including features, scenarios, and steps.[31] A # language: header at the file's start can reconfigure the lexer for non-English keywords, enabling localization in over 70 languages.[31] During execution, step matching against definitions handles potential ambiguities by requiring unique patterns; if multiple definitions match the same step text, an AmbiguousStepDefinitionsException is thrown to prevent nondeterministic behavior.[32] Unlike plain English, Gherkin mandates strict keyword usage—such as those for steps—to impose a formalized, executable structure that bridges natural language readability with programmatic precision.[30] This ensures scenarios are not merely descriptive but directly mappable to step definitions for automated testing.[32]Keywords and Usage Examples
Gherkin employs a structured set of keywords to define executable specifications in a human-readable format, enabling collaboration between technical and non-technical stakeholders in behavior-driven development.[30] These keywords provide semantic meaning to scenarios, distinguishing between setup, actions, outcomes, and organizational elements. The core keywords include Feature, which describes the high-level functionality under test and must appear at the beginning of a file, followed by a title and optional description.[30] Scenario outlines a specific example of the feature's behavior, typically containing 3-5 steps for clarity.[30] Given establishes the initial context or preconditions, such as "Given the user is not logged in."[30] When specifies the action or event that triggers the behavior, for instance, "When the user submits valid credentials."[30] Then asserts the expected outcome or postcondition, like "Then the user is redirected to the dashboard."[30] And and But serve as continuations to chain steps of the same type without repetition, enhancing readability; And follows the previous keyword's semantics, while But introduces contrast.[30] Background groups common setup steps that apply to all scenarios within a feature, reducing duplication.[30] Advanced keywords extend Gherkin's expressiveness for complex specifications. Scenario Outline (or its synonym Scenario Template) allows parameterization of a scenario template by replacing placeholders like<quantity> with values from an Examples table, enabling multiple executions with varied inputs.[30] For instance:
Scenario Outline: Eating cucumbers
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
Scenario Outline: Eating cucumbers
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
@, categorize features or scenarios for selective execution or reporting, such as @[smoke](/page/Smoke) for basic functionality tests or @regression for comprehensive suites.[30] Rule organizes related scenarios under a specific business rule, introduced in Gherkin version 6, to clarify intent without affecting execution.[30]
Practical usage often combines these keywords in domain-specific scenarios. A simple login example illustrates the Given-When-Then pattern:
Feature: User Authentication
[Scenario](/page/Scenario): Successful login
Given I am on the login page
When I enter valid credentials
Then I see the dashboard
Feature: User Authentication
[Scenario](/page/Scenario): Successful login
Given I am on the login page
When I enter valid credentials
Then I see the dashboard
# language: fr at the file's top enables these variations while preserving semantics.[34]
Implementation
Step Definitions
Step definitions in Cucumber serve as the bridge between declarative Gherkin steps and executable code, allowing behavior-driven development tests to perform actual actions or assertions. Each step definition consists of a matching pattern—typically a regular expression or Cucumber Expression—and a bound code block or method that implements the step's logic. When Cucumber processes a Gherkin scenario, it scans for step definitions that match the step's text, ignoring the leading keywords like Given, When, or Then, and executes the corresponding code if a match is found.[16] Implementation varies by programming language but follows a consistent pattern of associating the matcher with executable code. In Ruby, step definitions use a domain-specific language with keywords followed by a regular expression or expression and a do-end block; for instance:ruby
Given(/I have (\d+) cukes in my belly/) do |cukes|
@cukes = cukes.to_i
end
Given(/I have (\d+) cukes in my belly/) do |cukes|
@cukes = cukes.to_i
end
java
import io.cucumber.java.en.Given;
@Given("I have {int} cukes in my belly")
public void iHaveCukesInMyBelly([Integer](/page/Integer) cukes) {
this.cukes = cukes;
}
import io.cucumber.java.en.Given;
@Given("I have {int} cukes in my belly")
public void iHaveCukesInMyBelly([Integer](/page/Integer) cukes) {
this.cukes = cukes;
}
javascript
const {Given} = require('@cucumber/cucumber');
Given('I have {int} cukes in my belly', function (cukes) {
this.cukes = cukes;
});
const {Given} = require('@cucumber/cucumber');
Given('I have {int} cukes in my belly', function (cukes) {
this.cukes = cukes;
});
Hooks and Configuration
Cucumber hooks provide a mechanism to execute code at specific points during the test execution lifecycle, primarily for setup and teardown activities. These blocks of code run automatically and can be scoped to scenarios, features, or steps, allowing developers to manage application state without embedding such logic directly into step definitions. Hooks enhance test maintainability by centralizing common actions like database connections or logging.[32] The primary hook types include Before and After hooks, which execute immediately before and after a scenario or feature, respectively; Around hooks, available in Ruby, which wrap the entire execution of a scenario for precise control over timing; and step-level hooks like BeforeStep and AfterStep, which target individual steps within a scenario. By default, hooks apply to all scenarios unless scoped otherwise, such as limiting to a specific feature file. Tag filtering further refines execution: for instance, a Before hook annotated with "@slow" will only trigger for scenarios tagged with @slow in the Gherkin file, enabling conditional setup based on test categories.[32][38] Implementation of hooks varies by programming language due to Cucumber's multi-language support. In Ruby, the original language for Cucumber, Before and After hooks use block syntax:Before do |scenario| ... end for pre-scenario actions and After do |scenario| ... end for post-scenario cleanup, where the scenario parameter provides access to details like name and status. Around hooks in Ruby use block syntax to wrap scenario execution. In Java, hooks leverage annotations from the Cucumber JVM library: @Before for setup and @After for teardown, with methods receiving a Scenario object for context. Hook ordering can be controlled in Java via the order attribute, such as @Before(order = 1), ensuring predictable sequence when multiple hooks are defined. Custom formatters can integrate with hooks by attaching data (e.g., screenshots or logs) during After hooks, which then feeds into reporting plugins.[39][38][38]
Configuration in Cucumber varies by programming language and centralizes settings to avoid repetitive command-line arguments across runs. In Ruby, profiles are defined in a cucumber.yml file, placed in the project root or a config directory, encapsulating options such as output formatters (e.g., --format [json](/page/JSON)), paths to step definition directories (e.g., features/step_definitions), and tag filters to include or exclude scenarios (e.g., tags: ~@wip to skip work-in-progress tests). To activate a profile, specify it via the command line, such as cucumber -p ci. For Java and other implementations, configuration uses annotations like @CucumberOptions, command-line arguments, environment variables, or build tool profiles (e.g., Maven). Environment variables complement file-based or annotation-based configuration, with Cucumber parsing them alongside system properties and a cucumber.properties file for overrides; for example, setting DRY_RUN=true enables validation of step matching without full execution, useful for syntax checks during development. Advanced configurations support custom parameter types or data table conversions, but these are typically defined programmatically rather than in profiles.[40][40][32]
Usage
Command-Line Interface
The Command-Line Interface (CLI) of Cucumber provides a straightforward way to execute Gherkin feature files directly from the terminal, supporting standalone test runs without embedding in build tools.[32] It accepts paths to feature directories or files as arguments and applies options to control filtering, formatting, and execution behavior.[41] The CLI varies slightly by implementation but shares core options for consistency across languages.[32] Basic usage involves invoking the platform-specific command followed by feature paths. For Ruby, installed via thecucumber gem (gem install cucumber), the command is cucumber features/ or bundle exec cucumber features/my_feature.feature to run all scenarios in a file.[41] In Java (JVM), using the cucumber-core dependency via Maven or Gradle, it is java -cp "classpath" io.cucumber.core.cli.Main features/ --glue stepdefinitions or integrated via mvn test.[42] For JavaScript, installed as @cucumber/cucumber via npm (npm install --save-dev @cucumber/cucumber), the command is npx cucumber-js features/ or ./node_modules/.bin/cucumber-js features/.[43] These invocations load step definitions from specified glue paths and execute matching scenarios.[32]
Key options enable customization of runs. The --format (or --plugin) option specifies output formats such as progress for concise console updates, html for browser-readable reports, or json for machine-readable data (e.g., cucumber --format html --out reports/index.html).[17] The --tags option filters scenarios by tags (e.g., cucumber --tags "@smoke and not @slow" to run smoke tests excluding slow ones), allowing selective execution based on metadata defined in features.[32] The --dry-run flag performs a non-executing validation of step definitions against features, highlighting undefined or unused steps without invoking code (e.g., cucumber --dry-run).[41] Additionally, -p or --profile loads predefined configurations from files like cucumber.yml (Ruby) or system properties (Java).[40]
Output is directed to console by default, with progress bars or detailed summaries for passed/failed scenarios. Formatted reports are generated in specified directories, such as HTML files in ./reports/ for visual analysis or JSON in ./reports/cucumber.json for CI integration.[17] Console reporting includes color-coded indicators: green for passes, red for failures, and yellow for pending steps.[32]
Exit codes indicate run status: 0 for all scenarios passing, 1 for any failures or undefined steps, and 2 for syntax errors or configuration issues.[41] This enables scripting and CI/CD pipelines to react appropriately, such as failing builds on non-zero codes.[32]
Integration with Testing Frameworks
Cucumber-JVM integrates seamlessly with popular Java testing frameworks, enabling automated execution of Gherkin-based tests within established unit testing environments. For JUnit 4, developers add thecucumber-junit dependency to their project and annotate a runner class with @RunWith(Cucumber.class), which discovers and runs feature files as JUnit tests.[44] In JUnit 5, integration occurs via the cucumber-junit-platform-engine dependency and @Suite annotation on a test class, allowing parallel execution through Maven's Surefire plugin or Gradle.[45][42] Similarly, for TestNG, the cucumber-testng dependency is required, paired with a test class extending AbstractTestNGCucumberTests or using @CucumberOptions, supporting parallel runs by setting the data provider to true in TestNG XML configurations.[45][46]
Build tools facilitate dependency management and test execution for Cucumber-JVM projects. In Maven, core dependencies such as cucumber-java, cucumber-junit (or cucumber-testng), and gherkin are added to the pom.xml file under the test scope, with the Failsafe plugin configured to run Cucumber tests during integration phases like verify.[42][47] For Gradle, the cucumber-gradle-plugin or direct dependencies are applied in build.gradle, defining a cucumber task that leverages the Java plugin to execute tests alongside JUnit or TestNG runners.[48][49]
In the .NET ecosystem, Cucumber functionality is provided through SpecFlow, an official companion tool that implements Gherkin syntax and integrates directly with NUnit for test execution. SpecFlow projects include the SpecFlow.NUnit NuGet package, enabling feature files to run as NUnit test assemblies via attributes like [Binding] for step definitions and NUnit's [TestFixture]. This setup supports parallel execution and reporting within .NET build processes.
Cucumber embeds into CI/CD pipelines for automated testing and report aggregation. The official Cucumber Reports plugin for Jenkins parses JSON output from Cucumber runs, generating HTML visualizations of test results, pass/fail rates, and step details during builds.[50][51] For GitHub Actions, workflows typically use actions like setup-java to run Maven or Gradle commands that execute Cucumber tests, with artifacts uploaded for JSON reports and optional steps to publish summaries or integrate with external reporting services.
Enhanced reporting extensions build on Cucumber's JSON formatter for detailed visualizations. Allure integrates via the allure-cucumber7-jvm adapter, which attaches step traces, screenshots, and metadata to XML results, viewable in interactive dashboards after generation with allure serve.[52] ExtentReports uses the extentreports-cucumber adapter plugin in the runner's @CucumberOptions, producing HTML reports with categorized logs, timelines, and device/system info from Cucumber's execution output.[53]
Ecosystem
Supported Programming Languages
Cucumber provides official implementations in Ruby, Java (through Cucumber-JVM), JavaScript, and Go, enabling step definitions to be written natively in these languages while maintaining compatibility with the Gherkin syntax.[54] These core runtimes form the foundation for Behavior-Driven Development (BDD) testing across diverse environments. Additionally, community-maintained implementations exist for other languages, though they may vary in official endorsement and activity levels. The original Ruby implementation, known as Cucumber-Ruby, serves as the reference for the ecosystem and is highly mature, supporting installation via RubyGems with commands likegem install cucumber. It is widely used for its simplicity in scripting automated tests and remains actively maintained under community ownership since December 2024.[25]
Cucumber-JVM is the official Java implementation, popular in enterprise settings for its robustness and support for multiple JVM languages including Java, Groovy, Scala, and Kotlin.[42] It integrates seamlessly with build tools like Maven and Gradle, allowing step definitions to leverage the full power of the Java ecosystem for complex test automation.[55]
For JavaScript and TypeScript, Cucumber.js provides the official runtime, optimized for Node.js environments and browser-based testing. It supports integrations with popular frameworks such as Jest and Mocha, making it suitable for full-stack JavaScript applications and frontend testing scenarios.[56]
The Go implementation, godog, is an official port that allows writing step definitions in Go, emphasizing performance and concurrency for systems-level testing.
Among other notable implementations, Behat for PHP offers Cucumber-like BDD capabilities, installed via Composer, and is maintained independently but aligns closely with core principles. For Python, Behave serves as an unofficial yet widely adopted alternative, supporting Gherkin features through pip installation, though it is not directly under the Cucumber umbrella. In the .NET ecosystem, Reqnroll (a 2025 fork of the discontinued SpecFlow project) provides support via NuGet packages for Gherkin parsing and integrates with testing frameworks like NUnit and xUnit.[57] It relies on community extensions for full functionality and continues as the primary BDD tool for .NET aligned with Cucumber principles following SpecFlow's end-of-life in December 2024.[58]
As of December 2024, all Cucumber implementations have transitioned back to community ownership following the end of SmartBear's stewardship, resulting in varying maintenance activity across projects— with core ones like Ruby and JVM seeing consistent updates, while others depend on contributor engagement.[25]