[rspec-users] Stories, permissions, authorization rules etc.

Zach Dennis zach.dennis at gmail.com
Wed Dec 10 16:11:38 EST 2008


On Tue, Dec 9, 2008 at 3:52 AM, Andrew Premdas <apremdas at gmail.com> wrote:
> You can improve the features you've given by
>
> 1.  use named routes not url's
> 2.  not checking for not seeing specific things
> 3.  A combined step with a more examples table
>        Given I am logged in as a developer

#3 is  what I do. It works great,


> 4. having a general policy for what happens when access fails and testing
> that e.g. routing back to home page or where you came from
>
> 5. An uber combined step with a funky step matcher where the step definition
> would go through all the Roles and visit x with each one testing for an
> error
>        Given I am not a logged in developer I should get an error when I
> visit x
>
> '5' seems pretty ugly to me, but maybe in this case its bearable.
>
> Making the features  as simple as possible should reduce the resistance to
> their repitition
>
> As to the issue of using stories for coverage, I guess a balance has to be
> struck which is very dependent on business needs. If there are specific
> business rules that need to be enforced for a role then make that explicit
> in features. If the business rule is much more general and their are lots of
> role/access combinations then maybe do this in a more unit test way i.e. not
> in features
>
>
> 2008/12/9 Alberto Perdomo <alberto.perdomo at aentos.es>
>>
>> Hi,
>>
>> my team and i have come to the point where we have defined a whole
>> bunch of stories for an application.
>> Almost all of the actions (besides login, etc.) should *not* be
>> accesible if not logged in.
>> Almost all of the actions require a specific user role.
>>
>> So, my question is. How do you put that in stories?
>> I have come up with these different options:
>>
>> 1) In each story, e.g. 'Add a new issue', 'Comment issue', etc. you
>> define a few extra scenarios more or less like this:
>>
>> Scenario: Permission denied if not logged in
>> Given i am not logged in
>> When i visit 'issues/new'
>> I should see Permission denied
>> And i should not see 'Add Issue'
>>
>> Scenario: Permission denied if role not developer
>> Given i am logged in
>> And my role is not developer
>> When i visit 'issues/new'
>> I should see Permission denied
>> And i should not see 'Add Issue'
>>
>> ...
>>
>> 2) You could write a separate story (or multiple separate stories)
>> just for the matter of describing permissions and authorizarion rules.
>>
>> 3) You could just write scenarios for the role requirements (like 1)
>> and leave the logged_in scenario out, giving for granted that you are
>> going to make all actions inaccesible without logging in.
>>
>> I prefer option 1 although it feels not DRY. I think explicit stories
>> are good, and such important things as permissions etc. should not be
>> left out. My mates argue that there has to be a better solutions than
>> taking 50 stories and adding 2 o 3 scenarios that look more or less
>> the same to each of them.
>>
>> I don't like 2 because it breaks the granularity of the stories.
>> Stories should be more or less independant from each other. If you
>> decide not to implement a specific story then you would have to edit
>> again the permissions story. Also the permissions story will not pass
>> until you have implemented all the scenarios = until you have
>> implemented all the actions involved.
>>
>> I don't like 3 because it is against testing philosophy.You should not
>> rely on the memory of humans. That's one of the reasons to write
>> stories. Theoretically you could write something like a scenario that
>> goes through all your app routes and checks if they are accessible.
>>
>> So tell me.
>> How do you do such things?
>> Do you have any other approaches?
>> It's important to us from a cucumber/rspec perspective (how do you
>> test it?) but also from a requirements perspective (where do you write
>> down that part when gathering the user stories?).
>>
>> Cheers!
>> Alberto.
>> _______________________________________________
>> 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
>



-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com


More information about the rspec-users mailing list