[rspec-users] Cucumber, more examples, tabular data input sets

Zach Dennis zach.dennis at gmail.com
Sat Oct 18 16:51:03 EDT 2008


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


More information about the rspec-users mailing list