scenario outlines and tables

[Matt Stacey]

Hi,

I have raised a question on stack overflow regarding scenario outlines
and tables. I wonder if you might be able to point me in the right
direction?

http://stackoverflow.com/questions/5118860/specflow-cucumber-gherkin-using-tables-in-a-scenario-outline

Thanks in advance,
Matt.

[Darren Cauthon]

I offered my advice, hope it helps!


Darren

On Feb 25, 9:58 am, Matt Stacey <matthew.d.sta...@gmail.com> wrote:
> Hi,
>
> I have raised a question on stack overflow regarding scenario outlines
> and tables.  I wonder if you might be able to point me in the right
> direction?
>

> http://stackoverflow.com/questions/5118860/specflow-cucumber-gherkin-...
>
> Thanks in advance,
> Matt.

[Gáspár Nagy]

I think Darren has some good points in his post. Especially for this
concrete example.

Still, I can also agree on the original problem too. In some cases it
is annoying that you cannot parametrize a scenario outline with a
concrete table. I was even thinking on a kind of nested table syntax
long time ago: http://groups.google.com/group/specflow/browse_thread/thread/f552cdedd4f3eca9/c8d0f3e6582ee119

Now I think it is more important to have a stability of the language
than the feature richness. Especially for such a rarely required case.
I have checked the Cucumber tickets (https://rspec.lighthouseapp.com/
projects/16211-cucumber/tickets) but I haven't seen any that would be
for this problem.

Matt, if you have a good idea about how could you imagine supporting
this, you should post it to the Cucumber list IMHO. Usually there are
good discussions there about Gherkin extension ideas.

[Vagif Abilov]

In our development we are also struggling with output not easily supported by Cucumber/SpecFlow, but for the time being I am convinced that keeping simple rectangle data structure should be the best for non-technical people that we also target.
What I am afraid that once Cucumber supports tree-based table expansion (with multiple levels), it will be immediately misused to expose the content of relational databases. And keeping only one level is more relevant to specifications as provided by stakeholders.

Perhaps I just didn't work enough with complex scenario, but my impression so far is that making scenario fit Cucumber tables is worth the effort.

Vagif

[Darren Cauthon]

Not that I'm advocating for this, but...

Technically, if someone had to implement some complex object, or data
on an object that can change drastically (say, a MongoDB document...),
perhaps it could be done with the following?

Given I have a neat document like this
"""
{
"first_name" : "John",
"last_name" : "Galt",
"skills" : {
# continue your doc here
}
}
"""

or even do this:
Given I have a neat document like this
"""
{
"first_name" : "{0}",
"last_name" : "{1}",
"skills" : {
# continue your doc here
}
}
"""
And I want to replace the values in the neat document like this
| Id | Value |
| {0} | John |
| {1} | Galt |


Basically, if people just must go complex, maybe make your step
definition serialize the multi-line text from JSON to an object?

It is very late here, I'm very tired, and I have a feeling I'm going
to regret writing this email in the morning. But I was just thinking
while reading this stuff again: Maybe if people really need to do
this type of stuff, maybe we can just use other means instead of
trying to force it through Gherkin tables or scenario outlines?



Darren

On Feb 28, 4:39 am, Vagif Abilov <vagif.abi...@gmail.com> wrote:
> In our development we are also struggling with output not easily supported
> by Cucumber/SpecFlow, but for the time being I am convinced that keeping
> simple rectangle data structure should be the best for non-technical people
> that we also target.
> What I am afraid that once Cucumber supports tree-based table expansion
> (with multiple levels), it will be immediately misused to expose the content
> of relational databases. And keeping only one level is more relevant to
> specifications as provided by stakeholders.
>
> Perhaps I just didn't work enough with complex scenario, but my impression
> so far is that making scenario fit Cucumber tables is worth the effort.
>
> Vagif
>
>
>
>
>
>
>
> On Sun, Feb 27, 2011 at 9:01 PM, Gáspár Nagy <gaspar.n...@gmail.com> wrote:
> > I think Darren has some good points in his post. Especially for this
> > concrete example.
>
> > Still, I can also agree on the original problem too. In some cases it
> > is annoying that you cannot parametrize a scenario outline with a
> > concrete table. I was even thinking on a kind of nested table syntax
> > long time ago:

> >http://groups.google.com/group/specflow/browse_thread/thread/f552cded...

[Gáspár Nagy]

here is a related cucumber ticket:
https://rspec.lighthouseapp.com/projects/16211/tickets/429-multi-dimensional-scenario-outlines

it is not for hierarchical data, but for combinations, though.

[si_pa...@hotmail.com]

I have worked at several organisations now that have all ran into the same issue you describe here. This is one of the things that prompted me to (attempt) to start writing a book on the subject.

http://specflowcookbook.com/chapters/linking-table-rows/

Here I suggest using a convention which allows you to use the specflow table headers to indicate where the linked items come from, how to identify which ones you want, and then use the content of the rows to provide the data to "lookup" in the foreign tables.

For instance:

Scenario: Letters to Santa appear in the emailers outbox

Given the following "Children" exist
| First Name | Last Name | Age |
| Noah       | Smith     | 6   |
| Oliver     | Thompson  | 3   |

And the following "Gifts" exist
| Child from Children    | Type     | Colour |
| Last Name is Smith     | Lego Set |        |
| Last Name is Thompson  | Robot    | Red    |
| Last Name is Thompson  | Bike     | Blue   |