Cucumber & BDD Automation

It selects scenarios tagged @smoke that are not also tagged @wip. Cucumber tag expressions are boolean, with lowercase and, or, not and parentheses. Tags written on Feature, Rule, Scenario, Scenario Outline and Examples lines are inherited downward.

The glue option lists package names that Cucumber scans recursively for step definitions and hooks — packages, never file paths. Point it at the wrong package and every step of every scenario reports undefined, not just one line.

Cucumber substitutes an Examples value into the Scenario Outline's name, into step text, into the cells of a data table attached to a step, and into a doc-string body. Tags, comments and Background are never templated.

Cucumber-JVM registers a formatter with --plugin name:path or the cucumber.plugin property; cucumber-js uses --format name:path; Behave pairs --format with --outfile. Console and HTML output is written for people, while JSON, JUnit XML and message output is written for tools.

The World is cucumber-js's per-scenario context object, reachable as this inside step definition and hook functions. Cucumber builds a fresh World before every scenario and throws it away afterwards, so one scenario's state never reaches the next.

In a Cucumber Expression, {int} captures a whole number and passes an integer, {string} captures quoted text and strips the quotes, {word} captures one token with no whitespace, and {} captures anything and converts it to the method parameter's type.

cucumber-js loads support code from the paths in its import or require options, defaulting to files beside the feature files; loading a module is what registers its steps. setWorldConstructor replaces the per-scenario World, which steps reach through this.

@Before and @After wrap one scenario, @BeforeStep and @AfterStep wrap every individual step, and @BeforeAll and @AfterAll run once per JVM around the whole run. @After still runs when a step or a @Before hook fails.

Annotate a plain class with the JUnit Platform's @Suite and @IncludeEngines("cucumber"), then point it at the feature resources with @SelectClasspathResource. Cucumber's JUnit Platform engine must be on the test classpath; it then creates one test per scenario.

The parameter type your step method declares drives the conversion: a list of lists gives raw rows and no header, a list of maps keys each row by the first row, and a domain-type list needs a registered transformer.

A Cucumber step definition should call one intent-shaped method on an automation layer beneath it, such as a service client or a page object. Selectors, waits and driver calls belong in that layer, never in the glue class itself.

Cucumber-JVM reads the annotation string as a regular expression when it starts with a caret, ends with a dollar sign, or is wrapped in forward slashes; otherwise it parses it as a Cucumber Expression. In cucumber-js the argument type decides.

Behave loads features/environment.py and calls the hook functions it finds there by name: before_all, before_feature, before_scenario, before_step, before_tag and their after_ counterparts. Each is handed the same Context object, layered so scenario-level attributes vanish when the scenario ends.

Cucumber strips the keyword and matches the whole remaining sentence, so a conjunction step becomes one definition nothing else can reuse, and a failure cannot say which half broke. Split it into two steps with two definitions.

[Binding] marks a class whose step definitions and hooks SpecFlow/Reqnroll discover in the test assembly. Context injection builds those classes once per scenario from a scenario-scoped container, so several binding classes share one instance of a state class.

Rule groups the scenarios that illustrate one business rule, sitting between Feature and its scenarios. A Rule may carry its own Background, which applies only to that Rule's scenarios and runs after the feature-level Background, never instead of it.

The value closest to the run wins. On a JUnit Platform suite, @ConfigurationParameter is supplied with that suite's own discovery, so it beats a cucumber.properties file on the classpath root; that file is the weakest layer, a project-wide default.

A tag above one Examples block applies only to the scenarios generated from that block's rows, so it can select a group of rows. A tag on the Scenario Outline applies to every row of every Examples block below it.

Each line is one JSON envelope holding exactly one message: a parsed feature file, a compiled runnable scenario, a step result, an attachment. Cucumber's built-in HTML, JSON and JUnit formatters all consume that same stream rather than writing independently.

Both step definition classes declare the shared type as a constructor parameter. With cucumber-picocontainer present, PicoContainer builds the glue classes per scenario, creating one instance of that type and injecting the same reference into every class that asks.

Undefined means no step definition matched the line, and Cucumber prints a snippet stub for it. Ambiguous means more than one matched, so the runner refuses to choose. Pending means a matched definition signalled unfinished work. All three stop the scenario.

The .feature file ports, because the Gherkin grammar and its dialect data are shared across the family. Almost nothing below it does: step definitions, hooks, the per-scenario state object, data-table access, tag-filter syntax, configuration files and report formats are all implementation-specific.

Cucumber removes from each doc-string line up to as many leading whitespace characters as the opening triple-quote delimiter is indented by. Relative indentation survives, so moving the body relative to the delimiter silently changes a whitespace-sensitive payload.

The Scenario object both reports and writes: getName and getSourceTagNames identify the scenario, getStatus and isFailed give the outcome once the steps have run, attach adds bytes with a media type and a name, log adds text.

Give the hook a tag expression: @Before("@depot-db") in Cucumber-JVM, Before({tags: '@depot-db'}, fn) in cucumber-js. Unlike a Background, that setup is conditional, reaches scenarios in every feature file, and stays out of the reader's scenario text.

They tell Cucumber's own JUnit Platform engine to run scenarios concurrently inside one JVM, with a strategy that sizes the pool. The unit is the scenario, each Examples row included, so every scenario must own its state.

Register a @DataTableType per type when the table's columns are not the object's fields or you want unknown columns to fail loudly. Register one default entry transformer when many types bind field-for-field. With neither, conversion fails naming the type.

Allure attaches as an ordinary Cucumber plugin, writing intermediate result files that the Allure command line later renders into HTML. Serenity BDD wraps the run and needs a separate aggregation step. CI must clear stale results and archive the output.

Background runs before every scenario, and each Examples row is its own scenario - so four Background steps above a 23-row outline run 92 times. Keep Background for context a reader needs; move machinery nobody reads into a tag-filtered hook.