Compare

A different trade-off, not a replacement.

cucumber-rs ports classic Cucumber to Rust and does it well. rstest-bdd treats BDD as an extension of rstest, for teams already invested in cargo test.

Coming from cucumber-rs

Next door Marrow waves to the neighbours. Both picnics are going well.

Side by side

Where the two differ.

Both read Gherkin and run Rust steps. They part ways over who runs the tests and where state lives.

rstest-bdd and cucumber-rs compared
	rstest-bdd	cucumber-rs
Test runner	`cargo test`, with `rstest` underneath	Its own, started by `World::run(…)`
State	`rstest` fixtures, fresh per scenario	A `World` struct per scenario
Finding steps	Registered at compile time, matched at run time	Collected by the runner
Scenario Outlines	One `rstest` case per Examples row	Expanded by the runner
Async	Tokio current-thread, as an async scenario or through `TokioHarness`	Built in, on the runtime the runner is given
Missing steps	Fail at run time; a compile error under strict validation	Reported by the runner
Philosophy	BDD as an extension of `rstest`	A Rust port of classic Cucumber

Coming from cucumber-rs

The same ideas, different homes.

A cucumber-rs suite moves across concept by concept. The feature files do not change.

World

`A fixture, or several`

Each scenario gets fresh fixtures; a step asks for the ones it needs by name.

&mut World in a step

`&mut Fixture`

Steps take &mut to a fixture the scenario owns. No RefCell.

Option fields on the World

`Slot<T>`

Empty until a step fills it, reset in one call.

Expensive setup shared by all

`#[once] fixture`

Built once and kept read-only; per-scenario data is built from it.

#[given(expr = "…")]

`The same, accepted`

The step macros take expr = for a gentler move.

The runner’s filters

`cargo test filters and tags`

Tag expressions choose scenarios at compile time; test names filter at run time.

Choosing

Pick the one that suits the suite.

rstest-bdd, when…

the crate already tests with rstest, and scenarios should share its fixtures;
scenarios should run under cargo test, with its filters, parallelism, and IDE support;
each scenario’s state should be isolated by default.

cucumber-rs, when…

a dedicated runner, with its own output and hooks, is the point;
one World per scenario is the model the team wants;
async steps must run on a multi-threaded runtime.