Нулевой объект ответа в Rails 5.2, спецификации RSpec-Rails 3.7 для запроса GET

Question

Я был замешан в этом и чувствую, что, возможно, совершаю простую ошибку, но я не смог найти никакой информации по этой проблеме.

У меня есть некоторые спецификации запросов для Rails 5 и, когда я тестирую для перенаправления - но не для визуализированного шаблона - я получаю ошибку, undefined method 'response_code' for nil:NilClass, Причина этого, кажется, в том, что @response является nil когда вызывается сопоставитель (внутри кода ActionDispatch:: Assertions:: ResponseAssertions, а не в моем коде). Я могу использовать cURL, чтобы сделать запрос к API, и он возвращает ответ, как и ожидалось. Точка, где возвращается ошибка, находится здесь (это код ActionDispatch):

def generate_response_message(expected, actual = @response.response_code)
  "Expected response to be a <#{code_with_name(expected)}>,"\
  " but was a <#{code_with_name(actual)}>"
  .dup.concat(location_if_redirected).concat(response_body_if_short)
end

Обратите внимание на первую строку, где значение по умолчанию actual параметр установлен в @response.response_code,

Вот мой тестовый код:

RSpec.describe "Admin registrations", type: :request do
  describe "new sign-up" do
    subject { get new_admin_registration_path }

    it "redirects to home" do
       expect(subject).to redirect_to(new_admin_session_path)
    end
  end
end

Соответствующие строки в журнале испытаний:

Started GET "/admins/sign_up" for 127.0.0.1 at 2018-07-05 10:44:05 -0700
Processing by Admins::RegistrationsController#new as HTML
Redirected to http://example.org/admins/sign_in
Completed 301 Moved Permanently in 18ms (ActiveRecord: 0.0ms)

Интересно, когда я использую byebug, чтобы проверить значение subject, он возвращает объект Rack::MockResponse, так что это как-то не проходит.

Любая помощь, которую я могу получить с этим, высоко ценится!

Answer 1

Я уверен, что вы, вероятно, уже решили это, но для всех, кто может наткнуться на это, мы столкнулись с тем же (response не присваивается после выполнения запроса - либо get или же post, не пробовал другие методы, но предполагал, что все они будут одинаковыми). Все существующие спецификации запросов начали работать.

Виновник в нашем случае был отслежен до модуля, который требовался в rails_helper.rbи добавил к rspec's config.include список:

config.include ApiHelper, type: request

внутри AppHelper была коренная причина:

include Rack::Test::Methods

Комментируя эту строку (и, в конечном счете, для нас, удалив весь помощник, так как он не был действительно необходим), мы вернули спецификации запроса к их предыдущему и рабочему состоянию.

ТЛ; др:

Убедитесь, что вы не включаете Rack::Test::Methods в config.include для вашего rspec config непреднамеренно.

Answer 2

С моей стороны это довольно глупо, но я уверен, что кто-то другой или я сделаем это случайно.

Если type: :request уже установлен в вашем верхнем блоке, также убедитесь, что вы случайно не переопределили response переменная в вашем блоке.

В качестве предупреждения возьмем пример моего тупого себя:

let(:response) { }

it 'overrides rspec\'s own dediciated response variable' do
   get your_route_here_path
   expect(response).to have_http_status(:ok)
end

приводит к чему-то вроде:

Error: nil doesn't have property 'status'

Это потому что let(:response) фактически переопределяет собственный внутренний rspec response.

Просто имейте в виду, вы, вероятно, никогда так не облажаетесь, но на всякий случай.