GivenScenarios

We could also accept both scenarios:

GivenScenarios contained in the glider

where the glider can have as many scenarios as the user requires.

I'm thinking that GivenStory would be more suited as keyword, where the given story may contain one or more scenarios.

GivenStory doesn't make any sense to me. I'm starting to think that Story, being another BDD domain term, should be a completely separate object from Scenario (and the various types of Scenario). It might have Scenarios as part of it. To run a GivenScenario, we might want to identify which Scenario in the Story is being run.

Running all the Scenarios in a story to set up the context for anther Scenario makes no sense to me. Each Scenario could well leave the application in a different state, so what context would you set up in the Given? What state would you have, in which to perform the other steps?

No idea how Story as a separate object would work, but it feels like the right thing to do. Thoughts? 3.0 maybe?

I agree that story should be a separate model concept. The issue here is that we started with the Scenario concept and then added the ability to run multiple scenarios, which in my mind constitutes a story. So I would only run a story (ie a set of scenarios) to set up a context for another story - that's why I was thinking of calling it GivenStory. I think this could be retrofitted in 2.x codebase, possibly. Else we could branch off a 3.x and revisit the whole model to be more story-aware.

The alternative of keeping the GivenScenario as a context set up for each scenario is possible, but complicates the parsing IMO in case you had multiple GivenScenario in a single file. We need to evaluate which of the two use cases is more used. I'm thinking that most likely users would need a single setup call for all the scenarios in their file.

Bumping out of 2.2 release until consensus is reached on how to approach problem.

Just spotted this ticket and I thought I would chime in with how in Cucumber (http://wiki.github.com/aslakhellesoy/cucumber) we introduced GivenScenario and relatively swiftly decided to remove the feature in favour of other solutions.

I noted down some of the reasons why we removed it and what replaced it: http://blog.josephwilk.net/ruby/cucumber-waves-goodbye-to-givenscenario.html

Hope that might be of some relevance and help.

Thanks for your comments - interesting post.

The use case for GivenScenarios is still quite valid IMO - but it addresses a different concern from what you describe in your post, i.e. it's not about calling a scenario from another within the same feature. Rather it's about using a different story or feature as a pre-condition for a scenario. It's not meant to be called before each scenario (like background). You could debate whether it should be called GivenStory or GivenFeature but it does not change the substance of the matter.

This feature allows scenarios (or features) to have less repetition and be structured in a more modular and reusable way, without enforcing an order on the scenarios being run (e.g. by scenario file name). Experience in working with hundreds of scenarios has shown us how useful this feature can be, and it has been one of the most highly requested features I received as feedback. It is particularly useful when running in an IDE.

Added GivenScenarios: keyword which expects a CSV of scenario file paths as part of a scenario:

Scenario: A scenario with given scenarios as preconditions

GivenScenarios: path/to/scenario1, path/to/scenario2

Given ...
When ...
Then ...

Note that the GivenScenarios: must come before first Given/When/Then

Upon presence of given scenario paths, it will execute any scenario(s) contained in them before executing the steps of the scenaio.