Cannot use `response.status` nor `response.body`

[skalee]

Yeah, I know it's listed in gotchas already. Though it's a real inconvenience: it makes reusing RSpec matchers difficult.

There are some useful stock RSpec::Rails matchers which rely on response object presence. For example:

expect(response).to have_http_status(:ok)

Furthermore, many developers tend to write they very own matchers to be used in specs. Now they need to prepare yet another set of matchers for acceptance specs.

What's the reason for such behavior? I could implement the fake response object if there are no objections. If there are reasons to keep things as they are now, then I'd like to share with my workaround. Perhaps it's worth adding to the README:

resource "Accounts" do

  include RSpec::Rails::Matchers

  let(:response) { double status_code: response_status, response_headers: response_headers, body: response_body }

  post "/v2/account/sign_in" do
    parameter :email, "User e-mail", required: true
    parameter :password, "User password", required: true

    let!(:user) { create :user, signup_email: email, password: password }

    let(:email) { "api.user@example.test" }
    let(:password) { "api2134567" }

    example_request "Sign in with correct password" do
      expect(response).to have_http_status(:ok)
    end
  end

end

The response object mimics Capybara response so it doesn't depend on Rails' ActionDispatch::Response.

[oestrich]

I've never needed to use the same matchers between the tests, so I haven't run into this. If this is an issue for you I'd be happy to review a PR that fixes this problem.

[ariejan]

This is an issue for me, for instance, I can't re-use Airborne matchers to "deeply" match JSON types and values. Adding the let(:response) from @skalee works, but I'd rather not have to litter that around my specs.

[gayle]

Agreed, it would be "nice to have" to use rspec matchers like

expect(response).to be_success

expect(response).to be_unprocessable

expect(response).to be_forbidden

Checking equality on status 200 is obvious. But I always forget when I see a 403 or 422 that one of those is un-processable and one is forbidden. And then which is which. :)