I never spec my views. I also never put conditional logic in the views. If you have links that should show up sometimes and not others why not just move that logic into a helper or other associated class and test the method?
On Fri, Jun 5, 2009 at 10:04 AM, Zach Dennis <zach.den...@gmail.com> wrote: > On Fri, Jun 5, 2009 at 11:54 AM, Lee<lee.longm...@googlemail.com> wrote: > > I am driving out a view that renders a list of items with which a > > logged in member is associated. > > > > Against each item, one or more links may be rendered according to the > > member's role with respect to the item (item owner, item > > administrator, regular user etc). Each link represents a type of > > function that the member can perform on the item (edit, delete, invite > > etc), and the range of functions may differ across the items according > > to the member's role for each item. > > > > When specifying the view, should I include examples to specify which > > links should appear against an item for each potential role of a > > member? Or is this going too far? > > I don't think it's going to far. If certain links should not show up > in some cases, but should in others, I would provide an example for > those. If it's important enough to hide, it's important enough to make > sure it's hidden for the right reasons. > > > > > Here is an example list for a member: > > > > item 1 view edit delete (member is the owner of this item) > > item 2 view edit invite (member a regular user of this item) > > item 3 view (member has no role association with this item but can > > view it) > > I would probably drive these with a view spec that looked like this.... > > describe "your/view" do > it "should always have a link to view the item" > > context "when the member owns the item" do > it "should have a link to edit the item" > > it "should have a link to delete the item" > end > > > context "when the member owns the item" do > it "should have a link to edit the item" > > it "should have a link to invite ..." > end > end > > > > > > > Thanks. > > _______________________________________________ > > rspec-users mailing list > > rspec-users@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > -- > Zach Dennis > http://www.continuousthinking.com (personal) > http://www.mutuallyhuman.com (hire me) > http://ideafoundry.info/behavior-driven-development (first rate BDD > training) > @zachdennis (twitter) > _______________________________________________ > 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
