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

Jonathan Linowes jonathan at parkerhill.com
Tue Dec 9 02:50:47 EST 2008


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





More information about the rspec-users mailing list