Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Expose currently-execution scenario's name to step definitions via cucumber.api.Scenario.getName() #671

merged 4 commits into from Feb 21, 2014


None yet
3 participants

poetix commented Feb 20, 2014

(See pull request #670 for context)

I am using Cucumber to define tests for a system which calls out to a stub server that services HTTP requests:

Cucumber -[executes]-> step definition -[calls]-> system under test -[calls]-> stub server

The stub server works by recording and replaying a transcript of requests and responses, identified as belonging to a named scenario. Each Cucumber scenario corresponds to a scenario on the stub server, which is configured at execution-time with the expected sequence of requests and responses. In order to facilitate tracing and debugging between Cucumber, the system under test and the stub server, it is useful if the stub server's scenario can be matched by name to the Cucumber scenario which drives the behaviour that results in the stubbed HTTP calls.

As things stand, Cucumber-JVM does not provide access to a scenario's name or other details for code running within a step definition. This is by design, to prevent unwanted coupling (step definitions should be re-usable across scenarios, and indifferent to the particular scenario they are running in). However, in the use case described above, the step definition does not behave differently based on the scenario name; it merely passes the scenario name on to the stub server when recording its transcript of requests and responses. This does not result in any unwanted coupling, but makes it easier to trace calls across the system.

The change in this pull request exposes the currently-executing scenario's name via a getName() method on the cucumber.api.Scenario object which can be passed into a @before method in the step definitions.


aslakhellesoy commented Feb 20, 2014

This is exactly how I wanted it. LGTM.


poetix commented Feb 21, 2014

Any chance of this making it in? It would be cool not to have to maintain our own fork...

brasmusson added a commit that referenced this pull request Feb 21, 2014

Merge #671. Update History.md.
Also fix file modes and remove a wildcard import.

@brasmusson brasmusson merged commit 6d4e503 into cucumber:master Feb 21, 2014

1 check passed

default The Travis CI build passed

brasmusson commented Feb 21, 2014

Merged. Thanks for your contribution @poetix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment