rspec users - Oct 2008 - Cucumber, more examples, tabular data input sets

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 Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

Zach Dennis wrote:
> 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?
>
>   
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

Ben Mabey 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 Wilk
http://www.joesniff.co.uk
-- 
Posted via http://www.ruby-forum.com/.

On Sat, Oct 18, 2008 at 2:13 PM, Zach Dennis <zach.dennis at gmail.com>
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:
http://github.com/aslakhellesoy/cucumber/wikis/using-fit-tables-in-a-feature

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


-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

On Sat, Oct 18, 2008 at 4:25 PM, Stephen Eley <sfeley at gmail.com>
wrote:
> On Sat, Oct 18, 2008 at 2:13 PM, Zach Dennis <zach.dennis at
gmail.com> 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.
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:
>
http://github.com/aslakhellesoy/cucumber/wikis/using-fit-tables-in-a-feature
>
> 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 Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On Sat, Oct 18, 2008 at 10:25 PM, Stephen Eley <sfeley at gmail.com>
wrote:
> On Sat, Oct 18, 2008 at 2:13 PM, Zach Dennis <zach.dennis at
gmail.com> 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:
>
http://github.com/aslakhellesoy/cucumber/wikis/using-fit-tables-in-a-feature
>
> Posting that for the benefit of anyone else who missed it and
didn''t
> know they missed it.  So thank you!
>
Even *I* didn''t know about that page :-) I''ve just updated it.

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

Aslak
>
> --
> Have Fun,
>   Steve Eley (sfeley at gmail.com)
>   ESCAPE POD - The Science Fiction Podcast Magazine
>   http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Oct 18, 2008, at 9:51 pm, Zach Dennis 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/
http://aviewfromafar.net/

On Sat, Oct 18, 2008 at 5:42 PM, Ashley Moran
<ashley.moran at patchspace.co.uk> wrote:
>
> On Oct 18, 2008, at 9:51 pm, Zach Dennis 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.
>
I like what you''re thinking,

-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

(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 Dennis <zach.dennis at gmail.com>
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 Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

On Sat, Oct 18, 2008 at 7:37 PM, Stephen Eley <sfeley at gmail.com>
wrote:
> On Sat, Oct 18, 2008 at 4:51 PM, Zach Dennis <zach.dennis at
gmail.com> 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 Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On 18 Oct 2008, at 22:42, Ashley Moran wrote:
>
> On Oct 18, 2008, at 9:51 pm, Zach Dennis 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
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

Matt Wynne wrote:
> 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
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 Wilk
http://www.joesniff.co.uk

On 21 Oct 2008, at 15:47, Joseph Wilk wrote:
> Would you mind creating a ticket for it in lighthouse please?
Sure, that''s the easy part ;)

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