rspec users - Jun 2009 - Driving Out A View - Am I specifying too much?

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?

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)

Thanks.

On Fri, Jun 5, 2009 at 11:54 AM, Lee<Lee.Longmore at googlemail.com>
wrote:
>
> 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?
It depends.  If you''re doing full BDD on your view, using RSpec as a
design tool to plan the view before (or while) you create it, that
sounds totally appropriate.  Role-based hyperlinks sound like
important business features, not cosmetics or cruft, so they should be
declared and tested *somewhere* for sure.  If you do it this way, you
should make sure you''re only testing the view''s code, i.e. the
existence of the link, and not the logic that decides who can do what.
 (Which isn''t the proper job for a view.)

That said, view specs at a unit level tend to be a bit of a drag, and
many people skip them in favor of testing views at an integration
level.  You could put the same tests into Cucumber, or even a Selenium
or Watir browser suite, and drive it without having to set up all
those mock models in the view spec.

It isn''t a *bad* idea to spec the views too, though.  You
don''t lose
anything but time, and you may gain that back if the operation is a
sensitive one.  When I make decisions about whether to test
controllers or views in RSpec, I usually think about whether the code
is doing anything particularly complex or unusual, or if something in
it is exceptionally likely to break.  (And then, if either of those is
true, I think about whether I could simplify those vulnerabilities out
by reexamining my assumptions.)  >8->




-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

On Fri, Jun 5, 2009 at 11:54 AM, Lee<Lee.Longmore at 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 at 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)

On Fri, Jun 5, 2009 at 4:53 PM, Charlie Bowman<charlesmbowman at
gmail.com> wrote:
> 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?
Good point.  But if one is really being completionist, it still makes
sense to check that the view is calling that helper.


-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

Thank you everyone for your helpful insights.

I had already gone down the route suggested by Zach but it was
nevertheless very re-assuring to have my approach validated as I am a
newbie to RSpec. I did however consolidate my expectations e.g.:

  context "when the member is a privileged member of a zone" do

    it "should display links for functions (Create sub-zone, Invite
member, Invite non-member)" do
       .... "a" tag expectations for each expected link as well as the
use of :count to check the number of links e.g. function_links.should
have_selector("li", :count => 4)

To Charlie''s point, I do call a helper from my view to avoid
cluttering the view e.g.

  def function_links_for(functions, member, context)
    contents = content_tag(:li, link_to("Enter zone",
member_context_path(member, context)))
    functions.each do | function |
      case function.name
        when "ManageZone"
          contents << content_tag(:li, link_to("Manage zone",
edit_member_context_path(member, context)))
        when "RemoveZone"
        ....

''functions'' is an array of Function objects valid for member
and his/
her role for a given context (item).

But I opted not to test this explicitly but, I confess, on the basis
that Chapter 22 "Rails Helpers" in The RSpec Book is not yet written!

Thanks.

On 5 June, 22:36, Stephen Eley <sfe... at gmail.com>
wrote:
> On Fri, Jun 5, 2009 at 4:53 PM, Charlie Bowman<charlesmbow... at
gmail.com> wrote:
> > 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?
>
> Good point. ?But if one is really being completionist, it still makes
> sense to check that the view is calling that helper.
>
> --
> Have Fun,
> ? ?Steve Eley (sfe... at gmail.com)
> ? ?ESCAPE POD - The Science Fiction Podcast Magazine
> ? ?http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users