On Tue, Dec 9, 2008 at 3:52 AM, Andrew Premdas <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> >> 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@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
