Open hauleth opened 5 years ago
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
?
Pros:
feature Scenario name Scenario name
(so you see that Scenario name
is repeated).setup
only once, as setups are shared among all tests in describe
.Feature
in Scenario
, but you can have multiple Feature
in single file and multiple Scenarios
in single Feature
.describe
and test
hierarchy.describe
isn't a requirement for that.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
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).
@revati if you have multiple Feature
within single file, and then you implement setup
for Background
then these two will collide as both setup
s will run. Alternative is that describe
would be used for each Rule
and we would disallow multiple Feature
s per file.
I'm more inclined towards seconds option, as it would provide better integration with Rule
and disallow multiple Feature
s in single file.
Is it possible to create some sort of poll in github? 😅
No other way than "emoji voting".
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.
Feature
should be translated todescribe
andScenario
totest
.