RSpec View testing: How to modify params?

Question

I am trying to test my views with RSpec. The particular view that is causing me troubles changes its appearance depending on a url parameter:

link_to \"sort>

Answer 1

That's because you shouldn't be using params in your views.
The best way I see it to use an helper.

<div>Sorted by <%= sorted_by %></div>

And in one of your helper files

def sorted_by
    params[:sorted_by].capitalize
end

Then you can test your helpers quite easily (because in helpers tests, you can define the params request.

Answer 2

Another method of setting view params:

controller.request.path_parameters[:some_param] = 'a value'

Answer 3

If its a controller test then it would be

controller.stub!(:params).and_return {}

If its a helper test then it would be:

helper.stub!(:params).and_return {}

And its a view test it would be:

view.stub!(:params).and_return {}

If you get warning like below.

Deprecation Warnings:

Using `stub` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from /home/akbarbin/Documents/Office/projects/portfolio/spec/views/admin/waste_places/new.html.erb_spec.rb:7:in `block (2 levels) in <top (required)>'.


If you need more of the backtrace for any of these deprecations to
identify where to make the necessary changes, you can configure
`config.raise_errors_for_deprecations!`, and it will turn the
deprecation warnings into errors, giving you the full backtrace.

1 deprecation warning total

Finished in 4.86 seconds (files took 4.72 seconds to load)

You can change it into

allow(view).to receive(:params).and_return({sort_by: 'name'})

Answer 4

The easy way is to just do this:

helper.params = {:foo => '1', :bar => '2'}

But in general it's better to be more integration-y and not "stub" values when it's feasible. So I prefer to use controller tests with integrate_views. Then you can specify your params to the get, and test that the entire flow works, from sending params to the controller, to having them processed by the controller, and finally to rendering.

I also generally prefer to pull out view logic into helpers, which can be easier to test.

For instance, say I have a helper called selection_list, which returns a Hash whose "selected_preset" key relies on params[:selected_preset], and defaults to 42 if an empty value is specified for the param.

Here's a controller test where we've called integrate_views (you could of course do the same thing with an actual view test, if you're into that).

describe '#show' do
  describe 'selected_preset' do
    it 'should default to 42 if no value was entered' do
      get :show, :params => {:selected_preset => ''}
      response.template.selection_list[:selected_preset].should == 42

This integration test will alert me if some part of this functionality breaks. But I also would ideally like to have some unit tests to help me pinpoint that breakage.

I'll start by having the helper use an instance variable instead of directly accessing params. I'll change the above code by adding a single line directly below the get, as follows:

describe '#show' do
  describe 'selected_preset' do
    it 'should default to 42 if no value was entered' do
      get :show, :params => {:selected_preset => ''}
      assigns[:selected_preset].should == 42 # check instance variable is set
      response.template.selection_list[:selected_preset].should == 42

Now I also can easily perform a helper unit test:

describe MyHelper do
  describe '#selection_list' do
    it 'should include the selected preset' do
      assigns[:selected_preset] = 3
      helper.selection_list[:selected_preset].should == 3