On Wed, Dec 31, 2008 at 11:11 AM, aslak hellesoy
[email protected] wrote:
You can use assigns[:categories] and assigns[:sub_categories] to make
So do you recommend never doing helper specs?
I never said never Here is my manifesto styled take on this:
“I favour testing directly accessible APIs over indirectly accessible ones.”
In Rails, I usually try to write a spec against a controller or view before
I resort to a helper spec.
Keeping inappropriate logic out of the view helpers goes a long way to
allow for this IMO.
My personal rule of thumb of Rails view helpers is that they should
only be concerned with what is built, and not with the how or why.
Relying on instance variables is a no-no. When conditional checks come
into play there is usually something that can be abstracted. This is
where presenters excel.
Granted, not everything is always so black and white. When in doubt
there tend to be three ways to categorize presentation logic IMO:
- Is it site-wide? (ie: rounded_button_helper, date_format,
- Is it resource specific? (ie: order, line_item)
- Is it UI component/widget specific? (ie: scoreboard which is
compromised of multiple resources/models)
Site-wide things should go in Rails helper modules so they are easily
accessible. For the most part you can write implement these through
requirements imposed by scenarios and view specs. In other cases it
makes sense to write helper specs.
Logic that is resource specific or UI component/widget specific should
go inside of presenters. Rather than having (@category ||
@subcategory) conditionals floating around disorganized view helpers
you should be posing that question to something that cares.
This makes adding, extending, changing the logic surrounding the
concept in question easier because there is a concrete representation
that is organized and exists in a single spot – the presenter. When
you find you have multiple concepts sharing logic (but it’s not
site-wide) than extract out modules and include them in each
I don’t want to go to far off-topic from this thread, but needing to
directly test view helpers is much less frequent when you are putting
presentation logic where it belongs and writing examples for an
appropriate object and its public interface.
BTW, I agree with Aslak’s manifesto on this.