[rspec-users] DRYing up stories

Kamal Fariz kamal.fariz at gmail.com
Wed Jan 23 22:30:28 EST 2008


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 <ermok at tiscali.co.uk> 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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Regards,
Kamal



More information about the rspec-users mailing list