New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API for stateless step definitions #214

Closed
aslakhellesoy opened this Issue May 28, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@aslakhellesoy
Copy link
Contributor

aslakhellesoy commented May 28, 2017

Currently, the only way to pass state between step definitions is by storing state as instance variables.

This is cumbersome in some languages, in particular for Java where it becomes tricky to share state between classes. DI is the only way to address this.

For other languages (such as Ruby and JavaScript) the World often becomes a huge object holding all kinds of different state used by various step definitions.

I would like to propose an alternative API for Step Definitions where:

  • Each step definition (or hook) can return a value
  • This value is passed to the next step definition
  • Statically typed languages can use custom types

This would remove the need for a World or DI. It would reduce coupling and make it more explicit what is passed between step definitions.

We'll use this issue to discuss the implications of this in various implementations, and to come up with an API for various languages such as Java, Ruby and JavaScript (at least).

Once we're happy with the API we can create new issues to implement this in various Cucumbers.

(I've been thinking about this for a while, and I'm glad I am not the only one! See cucumber/cucumber-jvm#1136)

@mpkorstanje

This comment has been minimized.

Copy link
Contributor

mpkorstanje commented May 28, 2017

I think this solution trades a coupling a between step definitions and the World/DI modules for a coupling to the order in which steps in gherkin must be written. So I don't think this can be used to completely replace the World or DI modules. In the worst case you end up passing the World between steps.

For example take a website like Gmail that personalizes your account even when you are not logged in because it recognizes that nobody else ever uses that machine.

Given I am a specific kind of customer
And I have a login account that was previously used to login
When use the website
Then I am greeted with my name

In this scenario I'd have to pass the information about the customer (his name) from the first step all the way to last step through one or more steps that don't use the information.

But other then that yeah this can useful.

@mpkorstanje

This comment has been minimized.

Copy link
Contributor

mpkorstanje commented Jun 10, 2017

I found some past discussion about the same issue in Scala.

cucumber/cucumber-jvm#451

Edit: Wrong button. Sorry.

@paoloambrosio

This comment has been minimized.

Copy link
Member

paoloambrosio commented Aug 22, 2017

I am very much in favour of pure functions, or better of allowing both pure and impure step definitions for languages that were FP is not the main paradigm.

I think DI framework support is still needed to inject what is not part of the scenario context into the step definition class: components from the application or shared test dependencies (e.g. Selenium). In this way we don't need to handle different scopes for context parameters, as they should always have scenario scope, but we'd be flexible.

@stale

This comment has been minimized.

Copy link

stale bot commented Nov 8, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

@stale stale bot added the Stale label Nov 8, 2017

@stale

This comment has been minimized.

Copy link

stale bot commented Nov 15, 2017

This issue has been automatically closed because of inactivity. You can support the Cucumber core team on opencollective.

@lock

This comment has been minimized.

Copy link

lock bot commented Nov 15, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Nov 15, 2018

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