Helpers in view specs

Testing RSpec
1

I’m not sure of what the community stance is on this, but is there a
builtin way to include helpers in view specs? Is this practice shunned?
My thoughts on the matter are that I expect my views to have a specific
output, and sometimes it would be much easier to call the helper
function
in the view spec, so that that output could be expected. My helper
functions all have their own specs, so it would seem that I’m not doing
anything magical, just making the specs a little simpler.

Steve

2

On Feb 17, 2008 1:08 AM, Steve [email protected] wrote:

I’m not sure of what the community stance is on this, but is there a
builtin way to include helpers in view specs? Is this practice shunned?
My thoughts on the matter are that I expect my views to have a specific
output, and sometimes it would be much easier to call the helper function
in the view spec, so that that output could be expected. My helper
functions all have their own specs, so it would seem that I’m not doing
anything magical, just making the specs a little simpler.

http://rspec.info/rdoc-rails/classes/Spec/Rails/Example/ViewExampleGroup.html#M000037

3

On Sun, 17 Feb 2008 08:06:10 -0500, David C. wrote:

http://rspec.info/rdoc-rails/classes/Spec/Rails/Example/
ViewExampleGroup.html#M000037

I think that’s showing a way of maybe overriding existing helpers in the
view? What I’m asking is more like this:

http://pastie.caboo.se/153392

In the example I actually have “include ApplicationHelper” in there, and
am using a method “row_class_for_idx” in the spec. It works. I’m just
wondering if that’s bad form or not.

4

On Sun, 17 Feb 2008 12:40:31 -0500, David C. wrote:

Please do write back here if you do and let us know what you think.
By and large I agree with what Jay is saying, and I try to use literals
as much as possible already. I don’t try to make my specs DRY by any
means, and do in fact have much that is redundant because it improves
readability.

I do have some arguments for constants and variable values though. For
constants if you have the constant spec’d to ensure that it itself is
the
correct value, then why not use the constant in your specs? You’re not
saying that the code being tested has to use the constant, just that the
algorithm comes out correct. If the spec for the constant fails, you
know
that it’s not what it’s supposed to be. If you don’t layer your specs
like this, then I could see how it would be a problem, but I personally
spec my constants.

For variable values, such as using a method. Sometimes I just don’t
care.
The method being called is trivial. The example I presented above is
good. Right now row_class_for_idx returns “” for even, and “alt” for
odds. Let’s say in the future I wanted it to be “even”, and “odd” for
the
class names respectively. It’s a very simple requirement, used commonly
to make sure the lists are going to display properly. It seems like
something that’s just tedious to go back and change. Also since
row_class_for_idx has it’s own specs, I know that it will be putting out
what I want.

5

On Feb 17, 2008 11:17 AM, Steve [email protected] wrote:

not doing anything magical, just making the specs a little simpler.
In the example I actually have “include ApplicationHelper” in there, and
am using a method “row_class_for_idx” in the spec. It works. I’m just
wondering if that’s bad form or not.

You may want to give this a read:
Jay Fields' Thoughts: Testing: Expect literals.

Please do write back here if you do and let us know what you think.

Cheers,
David