Loading content
Cucumber is a BDD testing tool that supports executable specifications via Gherkin feature files. It enables collaboration between technical and non-technical stakeholders by mapping natural-language scenarios to automated tests. Cucumber integrates with many languages and CI systems to validate behaviour across the delivery pipeline.
Use this profile to understand the building block briefly, place it in the model, and open related building blocks.
Technical building block: can be automated, integrated, or operated.
Concrete cog in the system that works inside larger relationships.
Cucumber is a BDD testing tool that runs Gherkin feature files as executable specifications, letting examples verify code behaviour.
Cucumber was started by Aslak Hellesøy in the Ruby ecosystem to turn readable business scenarios into executable acceptance tests. The sources describe it first as a complement to RSpec; later implementations for additional languages followed. The core idea stayed the same: Gherkin links business language with automated verification.
A Cucumber run works like a translation chain: in a `.feature` file, Gherkin describes a feature through scenarios and steps. Cucumber reads those lines, matches each step to a Step Definition, and executes the underlying code. The result is a clear pass/fail signal and a report for each scenario; if no matching step exists, the step cannot be executed.
A way of working where examples and collaboration make requirements more precise and testable.
The readable language used in `.feature` files, built from fixed keywords and a simple structure.
A concrete flow with preconditions, an action, and an expected outcome.
Code bindings that connect text steps to program logic.
The same artefact serves as documentation and as an automated test.
Cucumber is useful when business and development need the same wording for acceptance criteria, for example before releases, for regression testing, or as continuously updated documentation in CI. It fits best when behaviour can be stated clearly and remains relatively stable. With many exceptions, vague wording, or heavily UI-driven detail, maintenance cost, coupling, and misinterpretation risk increase.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.