Проверить код состояния HTTP в одних экзаменах запросов RSpec rails, а в других - на поднятое исключение.

Возврат nil из частично смоделированной конфигурации приложения с

    context 'in production' do
      before do
        allow(Rails.application.config.action_dispatch).to receive(:show_exceptions)
      end

      it 'reports BAD REQUEST (HTTP status 400)' do
        perform_request
        expect(response).to be_a_bad_request
      end
    end

или более явно с

    context 'in production' do
      before do
        allow(Rails.application.config.action_dispatch).to receive(:show_exceptions).and_return nil
      end

      it 'reports BAD REQUEST (HTTP status 400)' do
        perform_request
        expect(response).to be_a_bad_request
      end
    end

работал бы, если бы это был единственный запущенный пример. Но если бы это было так, мы могли бы просто отказаться от настройки с config/environments/test.rb, так что это немного спорный вопрос. При наличии нескольких примеров это не сработает, поскольку Rails.application.env_config(), запрашивающий этот параметр, кэширует его результат.

Мокинг Rails.application.env_config() для возврата измененного результата

    context 'in production' do
      before do
        # We don't really want to test in a production environment,
        # just in a slightly deviating test environment,
        # so use the current test environment as a starting point ...
        pseudo_production_config = Rails.application.env_config.clone

        # ... and just remove the one test-specific setting we don't want here:
        pseudo_production_config.delete 'action_dispatch.show_exceptions'

        # Then let `Rails.application.env_config()` return that modified Hash
        # for subsequent calls within this RSpec context.
        allow(Rails.application).to receive(:env_config).
                                        and_return pseudo_production_config
      end

      it 'reports BAD REQUEST (HTTP status 400)' do
        perform_request
        expect(response).to be_a_bad_request
      end
    end

сделает свое дело. Обратите внимание, что мы clone результат env_config(), чтобы не изменить исходный хэш, который повлияет на все примеры.

    context 'in production' do
      around do |example|
        # Run examples without the setting:
        show_exceptions = Rails.application.env_config.delete 'action_dispatch.show_exceptions'
        example.run

        # Restore the setting:
        Rails.application.env_config['action_dispatch.show_exceptions'] = show_exceptions
      end

      it 'reports BAD REQUEST (HTTP status 400)' do
        perform_request
        expect(response).to be_a_bad_request
      end
    end

будет делать свое дело, но кажется немного грязным. Это работает, потому что Rails.application.env_config() дает доступ к базовому хешу, который он использует для кэширования своего результата, поэтому мы можем напрямую изменить его.

На мой взгляд, тест исключения не входит в спецификацию запроса; спецификации запроса обычно предназначены для тестирования вашего api с точки зрения клиента, чтобы убедиться, что весь стек вашего приложения работает должным образом. Они также похожи по своей природе на тесты функций при тестировании пользовательского интерфейса. Так как ваши клиенты не увидят это исключение, вероятно, оно не принадлежит к этому списку.

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

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

Мне было бы интересно увидеть код, который вы написали в своем контроллере, потому что его также можно использовать для определения стратегии тестирования. Если вы написали код, вызывающий исключение, это могло бы оправдать его тест, но в идеале это был бы модульный тест для контроллера. Это будет тест контроллера в rspec-rails среде.