Forum: RSpec newbie: need help to write the spec for helper

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
170b5dc385cc9ddf78ed01bcf1e6990a?d=identicon&s=25 Nasir Jamal (Guest)
on 2008-12-31 15:09
(Received via mailing list)
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
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-12-31 16:24
(Received via mailing list)
On Wed, Dec 31, 2008 at 8:00 AM, Nasir Jamal <nas35_in@yahoo.com> wrote:
>
> @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.

HTH,
David
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2008-12-31 16:59
(Received via mailing list)
On Wed, Dec 31, 2008 at 4:21 PM, David Chelimsky
<dchelimsky@gmail.com>wrote:

> > 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).

Aslak
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-12-31 17:03
(Received via mailing list)
On Wed, Dec 31, 2008 at 9:49 AM, aslak hellesoy
<aslak.hellesoy@gmail.com> wrote:
>> >
>> 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?
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2008-12-31 17:12
(Received via mailing list)
On Wed, Dec 31, 2008 at 5:02 PM, David Chelimsky
<dchelimsky@gmail.com>wrote:

> >> >
> >> > @categories is an instance of Category model
> >
> > 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.

Aslak
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-01-03 13:27
(Received via mailing list)
On 31 Dec 2008, at 16:11, aslak hellesoy wrote:

> before I resort to a helper spec.
>
> Aslak


Interesting. I've ended up going in the other direction. I started out
writing tests for UI code at the view level, treating helper methods
as implementation details, just as you're describing. This seemed to
result in view specs that were fragile, with lots of mocks to set up,
and duplicated spec logic where helper code was re-used in different
views. I now prefer to put all the interesting stuff in the helpers,
unit test that, use Cucumber to make sure the view doesn't blow up,
and do very little testing of the view itself.

I guess in the context of your little manifesto, I've started to think
of the methods you put in helpers as being the API that's used by the
designer who hacks on the views.


Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
F86901feca747abbb5c6c020362ef2e7?d=identicon&s=25 Zach Dennis (zdennis)
on 2009-01-08 04:49
(Received via mailing list)
On Wed, Dec 31, 2008 at 11:11 AM, aslak hellesoy
<aslak.hellesoy@gmail.com> wrote:
>> > wrote:
>> >> >  def test
>> >> 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:

 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
This topic is locked and can not be replied to.