View helpers not available in view specs

[wincent]

Just noticed that view helpers aren't automatically included in views like they were in RSpec 1, so you need to include them explicitly in all your view specs:

before do
  view.extend ApplicationHelper
  view.extend FooHelper
end

Is this intentional or still on the "to do" list?

Cheers,
Wincent

[dchelimsky]

We should add this. There is another approach:

helper(ApplicationHelper, FooHelper)

We can do that implicitly after determining the name of FooHelper from the path, and verifying the existence of ApplicationController.

Wanna make a patch for this?

[wincent]

Sure, will look into it.

[wincent]

Here's a shot at a patch:

http://gist.github.com/465592

But it can't be applied in its current form, as it breaks the Cucumber features for some reason I haven't been able to figure out yet; the failures look like this:

Then I should see "1 example, 0 failures"
  expected: /1\ example,\ 0\ failures/,
       got: "*.\n\n\nFinished in 0.02259 seconds\n2 examples, 0 failures, 1 pending\n\nPending:\n  rendering locals in a partial  (Not Yet Implemented)\n

[wincent]

Ok, revised version published here which doesn't break the Cucumber features:

http://github.com/wincent/rspec-rails/commits/issue-119

Specifically this commit:

http://github.com/wincent/rspec-rails/commit/10c3b979e577b8d7ab1efbd77e25cc441cb1d7bc

[wincent]

Just noticed that it's not enough just to include FooHelper and ApplicationHelper; there might be other helper methods defined in the controller(s) and made available via helper_method there:

Can't really see how to get at these though from within the ViewExampleGroup. The methods are visible in the @controller instance (actually a ActionView::TestCase::TestController instance) but they do not appear in @controller._helpers, nor does there appear to be any way of querying to find out what methods were passed into helper_methods (the method itself just does a class_eval and defines methods inside the _helpers module which delegate back to the controller).

I seem to recall this used to work in RSpec 1? Any ideas?

[dchelimsky]

Make view helpers available in view specs

This maintains the behavior established in RSpec 1.

Closed by http://github.com/rspec/rspec-rails/commit/a4200efc2d4af623fc32b65f3212daa8a39ad4c1

[dchelimsky]

I won't be able to research much until later today, but if take a look at http://github.com/dchelimsky/rspec-rails/blob/master/lib/spec/rails/example/view_example_group.rb#L115 if you feel so inclined. Not sure if that is doable in Rails-3, but if it is, that looks like the solution.

[wincent]

Been digging around by stopping a spec run and inspecting in the debugger, and have found that the methods defined using helper_method are visible in the spec context, via controller._helpers.instance_methods.

Looks like all helpers are there, though (ie. all helpers defined under app/helpers), not just the ones you get by including ApplicationHelper and the ModelHelper which corresponds to the controller whose views you are testing.

Do you think it is worth pulling in all this stuff? For me, it's basically either:

• include controller._helpers.instance_methods to get what I need, even though it means pulling in more methods than I need
• or having to stub a lot of calls in my view specs because so many views have calls to methods like admin?, logged_in?, current_user and so on, which are all defined as methods on ApplicationController and made available in views via helper_method
• refractor my application to get rid of all those helper_method calls; perhaps stick them in a module and then include that module in both ApplicationHelper an ApplicationController (probably having to use some kind of hacky thread-local storage)

The "least of all evils" choice seems to be the first option.

[dchelimsky]

It's a trade-off, but I think that, like you, most folks would rather have the helpers "just there" than have to stub them. Go for it.

[wincent]

Work in progress here:

http://gist.github.com/476715

Note that I include the methods in each view's metaclass; my first cut at this just did view.class.__send__(:include, ...), which ended up adding the methods into ActionView::TestCase, which doesn't seem like quite the right thing to do.

This works fine in my own application's specs, but I can't get the Cucumber spec to pass. Maybe I'm overlooking something.

[dchelimsky]

Cukes don't work because the setup doesn't support over-writing files that already exist in the generated app. Doing so would lead to an unwanted order dependencies between cukes.

Here's a modification that works: http://gist.github.com/476885

Note the implementation of _include_controller_helpers is slightly different too. Takes advantage of the singleton_class method in 1.9.2 (which Rails adds for earlier versions of Ruby).

[wincent]

Looks good.

[dchelimsky]

I wouldn't go that far :) The cuke is a little weird - maybe needs a comment to explain why it's being handled that way rather than defining admin? directly in ApplicationController.

[wincent]

It might be a little less obtuse if you do something like:

And a file name "controllers/secrets_controller.rb" with:
  """
  class SecretsController < ApplicationController
  protected
    def admin?; true; end
    helper_method :admin?
  end
  """

Instead of doing a class_eval in the spec file. I gather the setup would allow that seeing as it is not overwriting anything.

[dchelimsky]

I tried that first and it didn't work :) If you can get it to work, that's definitely preferable.