rspec users - Dec 2008 - newbie: need help to write the spec for helper

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





      
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081231/837a3fb0/attachment.html>

On Wed, Dec 31, 2008 at 8:00 AM, Nasir Jamal <nas35_in at 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.

HTH,
David
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Wed, Dec 31, 2008 at 4:21 PM, David Chelimsky <dchelimsky at
gmail.com>wrote:
> On Wed, Dec 31, 2008 at 8:00 AM, Nasir Jamal <nas35_in at 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).

Aslak

>
> HTH,
> David
>
> >
> >
> >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081231/e0fd646b/attachment.html>

On Wed, Dec 31, 2008 at 9:49 AM, aslak hellesoy
<aslak.hellesoy at gmail.com> wrote:
>
>
> On Wed, Dec 31, 2008 at 4:21 PM, David Chelimsky <dchelimsky at
gmail.com>
> wrote:
>>
>> On Wed, Dec 31, 2008 at 8:00 AM, Nasir Jamal <nas35_in at
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?
>
> Aslak
>
>>
>> HTH,
>> David
>>
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > rspec-users mailing list
>> > rspec-users at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/rspec-users
>> >
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Wed, Dec 31, 2008 at 5:02 PM, David Chelimsky <dchelimsky at
gmail.com>wrote:
> On Wed, Dec 31, 2008 at 9:49 AM, aslak hellesoy
> <aslak.hellesoy at gmail.com> wrote:
> >
> >
> > On Wed, Dec 31, 2008 at 4:21 PM, David Chelimsky <dchelimsky at
gmail.com>
> > wrote:
> >>
> >> On Wed, Dec 31, 2008 at 8:00 AM, Nasir Jamal <nas35_in at
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.

Aslak

>
> >
> > Aslak
> >
> >>
> >> HTH,
> >> David
> >>
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > rspec-users mailing list
> >> > rspec-users at rubyforge.org
> >> > http://rubyforge.org/mailman/listinfo/rspec-users
> >> >
> >> _______________________________________________
> >> rspec-users mailing list
> >> rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081231/a650f340/attachment.html>

On 31 Dec 2008, at 16:11, aslak hellesoy wrote:
> On Wed, Dec 31, 2008 at 5:02 PM, David Chelimsky  
> <dchelimsky at gmail.com> wrote:
> > 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

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

On Wed, Dec 31, 2008 at 11:11 AM, aslak hellesoy
<aslak.hellesoy at gmail.com> wrote:
>
>
> On Wed, Dec 31, 2008 at 5:02 PM, David Chelimsky <dchelimsky at
gmail.com>
> wrote:
>>
>> On Wed, Dec 31, 2008 at 9:49 AM, aslak hellesoy
>> <aslak.hellesoy at gmail.com> wrote:
>> >
>> >
>> > On Wed, Dec 31, 2008 at 4:21 PM, David Chelimsky <dchelimsky at
gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Dec 31, 2008 at 8:00 AM, Nasir Jamal <nas35_in at
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