Newbie: need help to write the spec for helper

Testing RSpec
1

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

2

On Wed, Dec 31, 2008 at 8:00 AM, Nasir J. [email protected] 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

3

On Wed, Dec 31, 2008 at 9:49 AM, aslak hellesoy
[email protected] 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?

4

On Wed, Dec 31, 2008 at 4:21 PM, David C.
[email protected]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

5

On Wed, Dec 31, 2008 at 5:02 PM, David C.
[email protected]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 :slight_smile: 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

6

On Wed, Dec 31, 2008 at 11:11 AM, aslak hellesoy
[email protected] 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 :slight_smile: 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. :slight_smile:

–
Zach D.
http://www.continuousthinking.com

7

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 W.
http://blog.mattwynne.net