rspec users - Dec 2008 - Stories, permissions, authorization rules etc.

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.

I usually assume my scenario user has been Given permission

and instead, I do the authorization testing in the controller specs  
with shared behaviors, for example,
it_should_behave_like "a login required action"
it_should_behave_like "a manager authorized action"

That said, I also might have a story where a user with the wrong  
permissions pokes around, but this is not a full coverage test at  
all. Its more for verifying how the app responds, with redirects or a  
message to the user, login prompt, etc.

--linoj


On Dec 8, 2008, at 7:03 PM, Alberto Perdomo wrote:
> 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

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
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081209/33b55d09/attachment.html>

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