Как включить промежуточное ПО в интеграционных тестах для стоечного приложения? - PullRequest
Новая
       38

Как включить промежуточное ПО в интеграционных тестах для стоечного приложения?

3 голосов
/ 01 апреля 2020

При написании интеграционных тестов для приложения Rack я хотел бы протестировать приложение со всеми промежуточными программами, которые включены в среде выполнения через файл classi c config.ru.

Использование стойки -app , я могу создать приложение Rack с помощью: 

describe App do

  include Rack::App::Test
  rack_app described_class

  describe '/hello' do
    get '/example/endpoint/'
    # ...
  end
end

С голым rack, это будет выглядеть так же: 

include Rack::Test::Methods
let(:app) { Application }

Но тогда нет включенных промежуточное программное обеспечение, поскольку приложение не создается с помощью config.ru, где их разрешают команды use.

Как включить промежуточное программное обеспечение в тестах, чтобы запросы выполнялись через них в примерах?

1 Ответ

1 голос
/ 15 апреля 2020

Является ли логика c в промежуточном программном обеспечении обязательным требованием для класса стойки-приложения?

Если да, то его следует использовать непосредственно в классе стойки-приложения, и оно должно быть просто spe c как обычно. Вы определяете тему приложения стойки с помощью rack_app ClassNameHere и проводите тестирование. Преимущество этого подхода в том, что вам не нужно знать с точки зрения spe c, что некоторые логики c находятся в промежуточном программном обеспечении, а некоторые - в части контроллера, поскольку они являются деталями реализации. Пока ожидаемое поведение выполняется в тестовых случаях spe c, оно должно быть хорошим.

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

Является ли логика c в промежуточном программном обеспечении формой контракта с приложением, например, промежуточное программное обеспечение обеспечивает значение в env вызова стойки, но значение не связано с промежуточным программным обеспечением, тогда я бы протестировал промежуточное программное обеспечение на свой. А в классе стойки-приложения spe c я бы гарантировал сущность в вызове стойки. Это поддержит аспекты долгосрочного обслуживания проекта, а также упростит многократное использование класса rack-app.

С другой стороны, если вам действительно нужно проводить совместное тестирование, но не использовать промежуточное ПО в классе напрямую, тогда Вы можете использовать следующую идиому в spe c: 

rack_app do
  use MiddlewareNameHere, params
  mount AppToTestWithTheMiddleware
end

Cheers, Adam

...