Slightly OT, but what can be done to DRY up steps? For aesthetics and more natural sounding stories, I often have things like
Given a user in the system and Given 2 users in the system where the small change is in the pluralization. What I currently do is to have two steps that essentially do the same thing (of course, converting 'a' to 1 before that). How can one alias a step? On Jan 24, 2008, at 8:04 AM, Ben Mabey wrote: > While the original post had DRY in the subject line I don't see this > as > a DRY issue. I see it as a visualization and maintenance issue. If I > add a new role and I want to test each action for it's permissions it > would be much easier for a customer to go down a spread sheet and > designate within each cell what the response should be.. success or > failure, etc... This would give the customer a bird's eye view of > permissions for the entire app for each class of users. By using a > separate scenario for each role in each story you will be creating a > lot > of copy and past work which will comminucate the same information a > spreadsheet would but a lot more inefficently since someone would have > to read hundreds of pages of stories. I love the plain text stories. > We just have to remember that there are better ways to express large > amounts of data than plain English. :) > Do you understand the point I'm trying to make? > > > -Ben > > > > aslak hellesoy wrote: >> On Jan 23, 2008 10:45 PM, Neil M. Young <[EMAIL PROTECTED]> wrote: >> >>> I'm finding that I'm writing sets of very similar scenarios to >>> check access >>> permissions for each of my actions. Does anyone have suggestions >>> on how to >>> dry this up: >>> >>> >> >> Beware that DRY has a cost. Clarity and readability. >> >> David's BDD manifesto (slightly rephrased): >> >> We prefer clarity over DRY (that is - while there is value in >> DRYness, >> we value clarity more) >> >> Aslak >> >> >>> Given an existing Account >>> And a logged in Admin >>> When the user visits account/manage >>> Then he should get access >>> >>> Given an existing Account >>> And a logged in Manager >>> When the user visits account/manage >>> Then he should get access >>> >>> Given an existing Account >>> And a logged in Supervisor >>> When the user visits account/manage >>> Then he should not get access >>> >>> Given an existing Account >>> And a logged in Reviewer >>> When the user visits account/manage >>> Then he should not get access >>> >>> Given an existing Account >>> And a logged in User >>> When the user visits account/manage >>> Then he should not get access >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/DRYing-up-stories-tp15053384p15053384.html >>> Sent from the rspec-users mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> >> _______________________________________________ >> rspec-users mailing list >> rspec-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users Regards, Kamal _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
