Forum: RSpec Cucumber, more examples, tabular data input sets

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Zach D. (Guest)
on 2008-10-18 22:14
(Received via mailing list)
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
http://www.mutuallyhuman.com
Ben M. (Guest)
on 2008-10-18 22:23
(Received via mailing list)
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
Joseph W. (Guest)
on 2008-10-18 22:55
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...
http://rspec.lighthouseapp.com/projects/16211/tick...

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

http://rspec.lighthouseapp.com/projects/16211-cucu...

> 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
Stephen E. (Guest)
on 2008-10-19 00:26
(Received via mailing list)
On Sat, Oct 18, 2008 at 2:13 PM, Zach D. <removed_email_address@domain.invalid>
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/usi...

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. (removed_email_address@domain.invalid)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
Zach D. (Guest)
on 2008-10-19 00:51
(Received via mailing list)
On Sat, Oct 18, 2008 at 4:25 PM, Stephen E. 
<removed_email_address@domain.invalid> 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:
> http://github.com/aslakhellesoy/cucumber/wikis/usi...
>
> 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
http://www.mutuallyhuman.com
aslak hellesoy (Guest)
on 2008-10-19 00:58
(Received via mailing list)
On Sat, Oct 18, 2008 at 10:25 PM, Stephen E. 
<removed_email_address@domain.invalid> wrote:
> that *look* like variable names, it sullies that.
>
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
Ashley M. (Guest)
on 2008-10-19 01:42
(Received via mailing list)
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/
http://aviewfromafar.net/
Zach D. (Guest)
on 2008-10-19 07:43
(Received via mailing list)
On Sat, Oct 18, 2008 at 5:42 PM, Ashley M.
<removed_email_address@domain.invalid> 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
http://www.mutuallyhuman.com
Stephen E. (Guest)
on 2008-10-19 07:48
(Received via mailing list)
(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. <removed_email_address@domain.invalid>
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. (removed_email_address@domain.invalid)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
Zach D. (Guest)
on 2008-10-19 07:57
(Received via mailing list)
On Sat, Oct 18, 2008 at 7:37 PM, Stephen E. 
<removed_email_address@domain.invalid> wrote:
> On Sat, Oct 18, 2008 at 4:51 PM, Zach D. <removed_email_address@domain.invalid> 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
http://www.mutuallyhuman.com
Matt W. (Guest)
on 2008-10-19 12:28
(Received via mailing list)
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
Joseph W. (Guest)
on 2008-10-22 08:28
(Received via mailing list)
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
Matt W. (Guest)
on 2008-10-22 11:12
(Received via mailing list)
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 ;)

http://rspec.lighthouseapp.com/projects/16211-cucu...
This topic is locked and can not be replied to.