Cucumber, more examples, tabular data input sets

Testing RSpec
1

Writing feature inputs in the tabular format has recently been very
helpful. However, there are some things that seem kind of funny when
writing. For example, let’s say we wanted to ensure that certain
requests resulted in the access denied page:

Given Joe is a staff member without the ‘admin’ privilege
When I GET /admin as Joe
Then I am notified that access was denied

The possible variables here based on step implementations are:

Given XXXX is a staff member without the ‘XXXX’ privilege
When I XXX XXXX as XXXX
Then I am notified that access was denied

This requires the More Examples to look like:

| name | privilege | request_method | path | name |
| Joe | admin | POST | /invoices | Joe |
| Joe | admin | PUT | /invoices/1 | Joe |
etc…

This isn’t that bad, but it’d be nice if we could specify only the
variable inputs that we care about – the privilege, the request
method and the path. As the scenario involves more steps you have to
grow your tabular data, unless I am missing how to do something (which
could be the case).

It also seems somewhat odd that the first example is the scenario
itself. It almost seems like the scenario should define the
placeholders and the More Examples section should define all the input
data sets. For example:

Given Joe is a staff member without the ‘$privilege$’ privilege
When I $request$ $path$ as Joe
Then I am notified that access was denied

Examples:
| privilege | request_method | path |
| admin | GET | /admin |
| admin | POST | /invoices |
| admin | PUT | /invoices/1 |

It would somewhat rely on using the $\w+$ pattern to denote what
should be replaced by the Examples input data set. I’m not tied to how
the inputs are grabbed, but it seems like moving in this direction
allows the tabular inputs to be more streamlined to what you wanted to
include in a scenario.

WDYT?

–
Zach D.
http://www.continuousthinking.com

2

Zach D. wrote:

It would somewhat rely on using the $\w+$ pattern to denote what
should be replaced by the Examples input data set. I’m not tied to how
the inputs are grabbed, but it seems like moving in this direction
allows the tabular inputs to be more streamlined to what you wanted to
include in a scenario.

WDYT?

Why is name even being used? Since you are talking in first person in
the other steps couldn’t you remove the name altogether:

Given I’m a staff member without the ‘admin’ privilege
When I GET /admin
Then I am notified that access was denied

As far as your suggestion about using placeholders instead of a real
example set- I like it. This was actually brought up a little while ago
by Evan Light on this list so I think it is something that people
naturally move towards. I think this way would be clearer to
non-developers as well since the column names would appear in the actual
scenario.

-Ben

3

Ben M. wrote:

As far as your suggestion about using placeholders instead of a real
example set- I like it. This was actually brought up a little while ago
by Evan Light on this list so I think it is something that people
naturally move towards.

As Ben said this has cropped up in a couple of places.

http://www.ruby-forum.com/topic/165523#new
http://evan.tiggerpalace.com/2008/09/11/plain-text-stories-at-dcrug/
http://rspec.lighthouseapp.com/projects/16211/tickets/4-add-multiline-step-support

It probably needs a new issue in lighthouse so we can focus discussion
there.

http://rspec.lighthouseapp.com/projects/16211-cucumber/overview

I think this way would be clearer to
non-developers as well since the column names would appear in the actual
scenario.

-Ben

I like the idea. Though I have some questions like how ‘GivenScenario’
would behave with such a scenario.

Joseph W.
http://www.joesniff.co.uk

4

On Sat, Oct 18, 2008 at 4:25 PM, Stephen E. [email protected] wrote:

that look like variable names, it sullies that.
I don’t know if it damages the scenario as a whole. After all, the
reason you’re using tabular data in the first place is so you can
re-use scenarios with different inputs. I would argue that using
variable names in the scenarios that use tabular data makes it more
readable. You can easily see where you are changing the inputs.
Otherwise you have to map each piece of tabular data with the
corresponding variable substitution locations for each step
definition. And if you update the step definitions at any point you
may break the scenarios that use tabular data because you need to go
update each row with updates or deletions of possible variables.

For example:

Given I login as Joe without the ‘admin’ privilege
When I GET /admin
Then I am notified that access was denied

More Examples:
| name | privilege | request_method | path | name |
| Joe | admin | POST | /invoices | Joe |
| Joe | admin | PUT | /invoices/1 | Joe |

The focus of these scenario is to make sure that when a user without a
particular privilege requests a specific path that they get sent to
the access denied page. So the three inputs I’m interested in are:
privilege, request method and path. The other ones are superfluous and
don’t speak clearly to actual intent of the tabular data that is
important.

Let’s say new types of users are added to the system, and I need
update the Given step to reflect that:

Given /^I login as the (.*) (\w+) without the ‘([^]’+)’ privilege$/

This makes the step in the scenario get updated to:
Given I login as the staff member Joe without the ‘admin’ privilege

Now I have to update each row of inputs to make sure they supply the
user type:

| name | user_type | privilege | request_method | path |
name |
| Joe | staff member | admin | POST | /invoices |
Joe |

Perhaps this scenario would have needed to be updated anyways because
I wanted to include varying user types for each run. But that isn’t
necessarily always the case. Perhaps the user type would never vary.
Why should it go in the tabular data? It’s not speaking clearly to the
intent the test, and the variables involved.

But by the way, thanks for posting this. I didn’t really grok the
tables feature in Cucumber before, and when I tried ‘script/generate
feature’ the table part threw errors so I deleted it. Your asking
made me look in the wiki on Github again, and I found this, which I
must have missed before:
GitHub: Let’s build from here · GitHub

Posting that for the benefit of anyone else who missed it and didn’t
know they missed it. So thank you!

yw! thx for joining the conversation,

–
Zach D.
http://www.continuousthinking.com

5

On Sat, Oct 18, 2008 at 2:13 PM, Zach D. [email protected]
wrote:

Given Joe is a staff member without the ‘$privilege$’ privilege
When I $request$ $path$ as Joe
Then I am notified that access was denied

My only beef with this is that it breaks the pattern of writing
scenarios in plain English. I don’t know if I can pin that down in
terms of technical value, but it makes me feel good to follow a
chain of turning prose into code. If you put variable names in there
that look like variable names, it sullies that.

But by the way, thanks for posting this. I didn’t really grok the
tables feature in Cucumber before, and when I tried ‘script/generate
feature’ the table part threw errors so I deleted it. Your asking
made me look in the wiki on Github again, and I found this, which I
must have missed before:

Posting that for the benefit of anyone else who missed it and didn’t
know they missed it. So thank you!

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

6

On Oct 18, 2008, at 9:51 pm, Zach D. wrote:

Given I login as Joe without the ‘admin’ privilege
When I GET /admin
Then I am notified that access was denied

More Examples:
| name | privilege | request_method | path | name |
| Joe | admin | POST | /invoices | Joe |
| Joe | admin | PUT | /invoices/1 | Joe |

How about just annotating them? eg

Given I login as [name] Joe without the ‘admin’ privilege
[missing_privilege]
When I GET [request_method] /admin [path]
Then I am notified that access was denied

Or whatever. Maybe do it selectively, I don’t think all of them are
necessary.

Maybe writing scenarios that read well above a table is just a skill
we have to develop.

Just a few thoughts really, I’m thinking out loud.

Ashley

–
http://www.patchspace.co.uk/

7

On Sat, Oct 18, 2008 at 5:42 PM, Ashley M.
[email protected] wrote:

| Joe | admin | PUT | /invoices/1 | Joe |

Maybe writing scenarios that read well above a table is just a skill we have
to develop.

Just a few thoughts really, I’m thinking out loud.

I like what you’re thinking,

–
Zach D.
http://www.continuousthinking.com

8

(I just realized that Zach was doing some sort of reply-all that
included my address separately, and had my reply going to him instead
of the list. So I’m sending it to the list now as I originally
intended.)

On Sat, Oct 18, 2008 at 4:51 PM, Zach D. [email protected]
wrote:

I don’t know if it damages the scenario as a whole. After all, the
reason you’re using tabular data in the first place is so you can
re-use scenarios with different inputs. I would argue that using
variable names in the scenarios that use tabular data makes it more
readable.

I didn’t say it damaged it. Your logic is fine. It simply makes it
look less like an English prose sentence, and that’s counter to the
aesthetic that’s part of Rspec’s/Cucumber’s appeal to my personal
taste.

Which I guess is less a strenuous objection, and more just to say:
Aslak, if this suggestion is officially implemented in Cucumber,
please make sure the current form continues to work too. Then those
of us who are persnickety fiction editors can continue doing things
the way we like them, and everybody wins. >8->

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

9

On Sat, Oct 18, 2008 at 7:37 PM, Stephen E. [email protected] wrote:

On Sat, Oct 18, 2008 at 4:51 PM, Zach D. [email protected] wrote:

I don’t know if it damages the scenario as a whole. After all, the
reason you’re using tabular data in the first place is so you can
re-use scenarios with different inputs. I would argue that using
variable names in the scenarios that use tabular data makes it more
readable. You can easily see where you are changing the inputs.

I didn’t say it damaged it.

Well you said sully, and that is defined as “damaging the purity or
integrity of; defile”.

Your logic is fine. It simply makes it
look less like an English prose sentence, and that’s counter to the
aesthetic that’s part of Rspec’s/Cucumber’s appeal to my personal
taste.

Which I guess is less a strenuous objection, and more just to say:
Aslak, if this suggestion is officially implemented in Cucumber,
please make sure the current form continues to work too. Then those
of us who are persnickety fiction editors can continue doing things
the way we like them, and everybody wins.

Based on your earlier email you mentioned you hadn’t really grokked
the tabular inputs of features, so I’m guessing you haven’t been using
the current form. I’m not asking to change how single scenarios are
written. I am just asking for a more useful way to write scenarios
which use tabular data inputs. The typical scenario wouldn’t be
affected by this.

I like Ashley’s idea of annotating the inputs. You could annotate only
those that should be replaced with data from the tabular inputs.

–
Zach D.
http://www.continuousthinking.com

10

On 18 Oct 2008, at 22:42, Ashley M. wrote:

| Joe | admin | PUT | /invoices/1 | Joe |

How about just annotating them? eg

Given I login as [name] Joe without the ‘admin’ privilege
[missing_privilege]
When I GET [request_method] /admin [path]
Then I am notified that access was denied

I like this, and I agree with Joe that it’s quite painful to have to
(a) include every substitutable step parameter in the table columns,
even if it doesn’t change in any scenario table row
(b) go hunting around in step definitions (or pretty console output
looking for the underlines) to figure out which param is which

But I do also feel like it clutters up the scenario bit.

I wonder whether it might also work to have a different definition,
like ScenarioTemplate: which doesn’t actually run, but defines the
skeleton into which the table values will be substituted. So Joe’s
example will work like this:

ScenarioTemplate: Non admins are rejected
Given I login as Joe without the ‘[privilege]’ privilege
When I [request_method] /admin[path]
Then I am notified that access was denied

| privilege | request_method | path |
| Joe | GET | /admin |
| Joe | POST | /invoces/1 |

etc.

WDYT?

cheers,
Matt

11

Matt W. wrote:

WDYT?

cheers,
Matt

This sounds like a good direction Matt.

I think its important to make it clear that it is not a normal scenario
to avoid step matching confusion/why is this not being run.

Would you mind creating a ticket for it in lighthouse please?

Thanks,

Joseph W.
http://www.joesniff.co.uk

12

On Sat, Oct 18, 2008 at 10:25 PM, Stephen E. [email protected] wrote:

that look like variable names, it sullies that.

Even I didn’t know about that page :slight_smile: I’ve just updated it.

(Let’s not call them FIT tables. Let’s call them scenario tables and
step tables instead).

Aslak

13

On 21 Oct 2008, at 15:47, Joseph W. wrote:

Would you mind creating a ticket for it in lighthouse please?

Sure, that’s the easy part :wink:

http://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/57-scenario-templates-to-allow-for-terse-scenario-tables