Skip to content
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

Scenarios should be grouped by feature #73

Open
hauleth opened this issue Feb 27, 2019 · 7 comments
Open

Scenarios should be grouped by feature #73

hauleth opened this issue Feb 27, 2019 · 7 comments

Comments

@hauleth
Copy link
Contributor

hauleth commented Feb 27, 2019

Feature should be translated to describe and Scenario to test.

@revati
Copy link
Collaborator

revati commented Feb 27, 2019

Currently, each Scenario is wrapped in separate describe. Don't know exactly what was initial intent, but what you are asking seems doable.

Except: as of gherkin 6 there is a new concept: Rule which brings one more layer of depth.

While it seems doable, what benefit would it have? In the final output, each scenario should be a test, everything outside that is open for change.

One more case, would be, that there always is only one Feature, can there even be two Features in one Scenario?

@hauleth
Copy link
Contributor Author

hauleth commented Feb 27, 2019

Pros:

  1. It will have more descriptive name in case of test failures and/or issues, currently it is feature Scenario name Scenario name (so you see that Scenario name is repeated).
  2. You will need to translate background to setup only once, as setups are shared among all tests in describe.
  3. You cannot have multiple Feature in Scenario, but you can have multiple Feature in single file and multiple Scenarios in single Feature.

@revati
Copy link
Collaborator

revati commented Feb 27, 2019

  1. Naming can and should be fixed regardless of describe and test hierarchy.
  2. it can be done in global scope as well. describe isn't a requirement for that.
  3. If that (one can have multiple Features in single *.feature file) is true, it is odd. Even then have them wrapped around in describe isn't a requirement.

Currently, it seems for me it there are 2 possible ways regarding describe

  • it won't be used at all
  • it will wrap each test (scenario).

Dunno. In either case, it isn't neither a primary concern, nor one that somehow drastically would change how lib interacts with end user (developer).

@hauleth
Copy link
Contributor Author

hauleth commented Feb 27, 2019

@revati if you have multiple Feature within single file, and then you implement setup for Background then these two will collide as both setups will run. Alternative is that describe would be used for each Rule and we would disallow multiple Features per file.

@revati
Copy link
Collaborator

revati commented Feb 27, 2019

I'm more inclined towards seconds option, as it would provide better integration with Rule and disallow multiple Features in single file.

Is it possible to create some sort of poll in github? 😅

@hauleth
Copy link
Contributor Author

hauleth commented Feb 27, 2019

No other way than "emoji voting".

@revati revati added 1.0 and removed 1.0 labels Feb 28, 2019
@mononym
Copy link
Contributor

mononym commented Mar 4, 2019

Cucumber doesn't even support multiple features in a single file:
https://stackoverflow.com/questions/30599752/multiple-feature-inside-single-feature-file

I don't think that should be something to worry about. Either the things in the single file being tested are so closely related that they are part of the same feature, or they are separate enough that they deserve their own feature files. This seems to be the philosophy they are following.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants