Мониторинг и тестирование независимых сторонних API-интерфейсов на Rails - программирование
Подтвердить что ты не робот

Мониторинг и тестирование независимых сторонних API-интерфейсов на Rails

Мы хотели бы настроить автоматические задания (через Jenkins), чтобы предупредить, если сторонний API недоступен или они развернули несовместимые API.

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

У кого-нибудь есть этот опыт в этом прежде? (Я не ограничен Ruby/Rspec, если другие инструменты могут помочь)

4b9b3361

Ответ 1

Mocks используются для тестирования ВАШЕГО СОБСТВЕННОГО кода без касания реального API. И вы хотите протестировать настоящий API.

Итак, я думаю, что вам нужно написать набор тестов в RSpec, например, для теста ненавязчивого стороннего API.
Под "ненавязчивым" я имею в виду отслеживание, чем вы, например, не выдаете случайные запросы API "DELETE" или используете все ограничения API ежедневных запросов при выполнении одного тестового набора.

Не знаю, существуют ли указанные средства тестирования API. Что касается меня, я использовал RSpec для успешного тестирования своих удаленных API/серверов.

Ответ 2

Вы видели VCR? Используя его, вы можете "записывать ваши тестовые пакеты HTTP-взаимодействия и воспроизводить их во время будущих тестовых прогонов для быстрых, детерминированных и точных тестов". Я использовал его с RSpec при тестировании ожидаемых ответов от внешних API, и думаю, что это здорово. Я бы посоветовал вам проверить вопросы StackOverflow с тегами , если вы думаете, что это может сработать для вас.

Не уверен в интеграции Jenkins, но когда я использовал видеомагнитофон, я автоматизировал некоторые обычные задачи, в которых мне нужно было поразить API с помощью Whenever ( "Работы Cron в Ruby" ). Не совсем непрерывный, но несколько автоматизированный.

Ответ 3

Когда я был в этой ситуации несколько месяцев назад, я сделал следующее:

  • Откажитесь от API и напишите тесты против издевающихся данных (у вас уже есть это)
  • Напишите еще один тест, который получает данные от реального API и утверждает, что он (все еще) в той же форме и содержит те же самые данные, которые мы ожидаем

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

Ответ 4

Есть 2 вещи, которые я сделал бы с существующим набором тестов, чтобы он мог использоваться вживую, первый использует возможность для блоков describe и it принимать метаданные (Там есть хорошая запись в блоге здесь). Второй использует возможность для shared_contexts взять блок.

Во-первых, отметьте спецификации, которые вы хотите запустить против реального API с метаданными. Например, вы хотите знать, что они могут быть выполнены для реальных, например.

describe "Hitting the API with a call", :can_be_real do
  # …
end

Затем эти спецификации можно запустить из командной строки с помощью параметра тега.

Во-вторых, нужно заменить насмешки реальной. Это зависит от того, как вы определили макеты, использовался ли before или let, и насколько вы издевались. Как глупый пример, см. Ниже:

require 'rspec'

RSpec.configure do |c|
  c.treat_symbols_as_metadata_keys_with_true_values = true
end

shared_context "all my mocks and stubs" do
  let(:this) { false }
end

describe "a", :real do
  include_context "all my mocks and stubs" do
    let(:this) { true } if ENV["REAL_API_CALL"] == 'true'
    before do
      stub_const( "URI", Class.new ) unless ENV["REAL_API_CALL"] == 'true'
    end
  end
  it "should be real when it real" do
    this.should == true
  end
  it "should escape things when it real" do
    URI.should respond_to :escape
  end
end

Когда файл запускается через bin/rspec example.rb, вывод:

a
  should be real when it real (FAILED - 1)
  should escape things when it real (FAILED - 2)

Failures:

  1) a should be real when it real
     Failure/Error: this.should == true
       expected: true
            got: false (using ==)
     # ./example.rb:19:in `block (2 levels) in <top (required)>'

  2) a should escape things when it real
     Failure/Error: URI.should respond_to :escape
       expected URI to respond to :escape
     # ./example.rb:22:in `block (2 levels) in <top (required)>'

Finished in 0.00349 seconds
2 examples, 2 failures

При запуске через env REAL_API_CALL=true bin/rspec example.rb:

a
  should be real when it real
  should escape things when it real

Finished in 0.00301 seconds
2 examples, 0 failures

Итак, вы видите, вы можете изменить контекст спецификаций несколькими способами, которые позволили бы вам контролировать уровень управления из командной строки (и, следовательно, Дженкинса). Вы хотели бы пометить спецификации другими метаданными, например, безопасно ли работать для реального времени, может ли это длиться долгое время и т.д.