为什么Rspec使用错误的对象进行控制器测试？

Question

We have an API which we returns some structured JSON data. Sites have_many :controllers, and Controllers belong_to :site

For the test, we have to create a mock site and controller, which is achieved in all our other feature test files exactly like I have it listed below in the before(:each) do block.

Test:

describe Api::V2::SitesController, :type => :controller do
    render_views

    before(:each) do
        basic_auth_and_skip_hmac
        @site = FactoryGirl.create(:site)
        @user_site = FactoryGirl.create(:user_site, user: @user, site: @site)
        @controller = FactoryGirl.create(:controller, site: @site)
    end

    it 'List all sites' do
        get :index, format: :json
        puts response.body
        expect(response.body).to include("Site 1")
        expect(response.body).to include("Controller 1")
    end


end

But the response for this controller test is unexpected:

Api::V2::SitesController
  List all sites (FAILED - 1)

Failures:

  1) Api::V2::SitesController List all sites
     Failure/Error: get :index, format: :json
     NoMethodError:
       undefined method `response_body=' for #<Controller:0x0000010db0c2d8>

Why do you even care about response_body for the Controller object Rspec? It clearly states at the top that we're describing the SitesController!

Removing the creation of the controller object and the matching expectation at the bottom of the file makes the test pass as expected:

Finished in 0.60435 seconds (files took 5.38 seconds to load)
1 example, 0 failures

But I'm not really testing everything I set out to test because my JSON includes:

"controllers":[]

Which technically cannot happen in our application. The controller is the most important unit to measure for us, so returning a JSON response with valid site information but no controllers would be pointless.

Answer 1

As shown in the discussion above with Mike - it turns out that "@controller" is special to Ruby.

And I happen to work in probably the only industry where this becomes a naming conflict. We manage a service for irrigation controllers, so the word is always messing with my head - am I talking about MVC controller or the actual device?

It's been a burden that probably no one else will ever encounter as it's just not a variable you would ever think to use.

In summary - don't ever call @controller, pretty much anywhere.