On Sat, Oct 18, 2008 at 4:25 PM, Stephen Eley <[EMAIL PROTECTED]> wrote: > On Sat, Oct 18, 2008 at 2:13 PM, Zach Dennis <[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.
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 _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
