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)
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->
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”
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.
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?
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.