On Wed, Dec 31, 2008 at 11:11 AM, aslak hellesoy
<aslak.helle...@gmail.com> wrote:
>
>
> On Wed, Dec 31, 2008 at 5:02 PM, David Chelimsky <dchelim...@gmail.com>
> wrote:
>>
>> On Wed, Dec 31, 2008 at 9:49 AM, aslak hellesoy
>> <aslak.helle...@gmail.com> wrote:
>> >
>> >
>> > On Wed, Dec 31, 2008 at 4:21 PM, David Chelimsky <dchelim...@gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Dec 31, 2008 at 8:00 AM, Nasir Jamal <nas35...@yahoo.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > I am a rspec newbie, can anyone guide me on how to write a spec for
>> >> > the
>> >> > below helper.
>> >> >
>> >> > module MyHelper
>> >> > def test
>> >> > link_to('MyLink', resources_path) if @categories ||
>> >> > @sub_categories
>> >> > end
>> >> > end
>> >> >
>> >> > @categories is an instance of Category model
>> >> > @sub_categories is an instance of SubCategory model
>> >>
>> >> Take a look at
>> >> http://rspec.info/documentation/rails/writing/helpers.html.
>> >> You can use assigns[:categories] and assigns[:sub_categories] to make
>> >> the necessary data available to the helper.
>> >
>> > Technically you can do it that way, but personally I don't recommend
>> > that
>> > approach in most cases. Testing modules is similar to testing private
>> > methods, and the general advice is: Don't do it.
>> >
>> > Instead, test module methods and private methods indirectly via the
>> > class/object that uses them. For modules this means: Write a spec for a
>> > class that includes the module (in Rails this is a controller or view).
>>
>> 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:
1. Is it site-wide? (ie: rounded_button_helper, date_format, money_format)
2. Is it resource specific? (ie: order, line_item)
3. 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
presenter.
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. :)
--
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
