Мониторинг и тестирование независимых сторонних API-интерфейсов на Rails
Мы хотели бы настроить автоматические задания (через Jenkins
), чтобы предупредить, если сторонний API недоступен или они развернули несовместимые API.
Я говорю о том, чтобы протестировать реальный HTTP APIs
, а не макет, но, как мы уже писали, используя rspec
, я не уверен, что мы должны дублировать усилия, написав два независимых теста.
У кого-нибудь есть этот опыт в этом прежде?
(Я не ограничен Ruby/Rspec
, если другие инструменты могут помочь)
Ответы
Ответ 1
Mocks используются для тестирования ВАШЕГО СОБСТВЕННОГО кода без касания реального API. И вы хотите протестировать настоящий API.
Итак, я думаю, что вам нужно написать набор тестов в RSpec, например, для теста ненавязчивого стороннего API.
Под "ненавязчивым" я имею в виду отслеживание, чем вы, например, не выдаете случайные запросы API "DELETE" или используете все ограничения API ежедневных запросов при выполнении одного тестового набора.
Не знаю, существуют ли указанные средства тестирования API.
Что касается меня, я использовал RSpec для успешного тестирования своих удаленных API/серверов.
Ответ 2
Вы видели VCR? Используя его, вы можете "записывать ваши тестовые пакеты HTTP-взаимодействия и воспроизводить их во время будущих тестовых прогонов для быстрых, детерминированных и точных тестов". Я использовал его с RSpec при тестировании ожидаемых ответов от внешних API, и думаю, что это здорово. Я бы посоветовал вам проверить вопросы StackOverflow с тегами vcr, если вы думаете, что это может сработать для вас.
Не уверен в интеграции 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
Итак, вы видите, вы можете изменить контекст спецификаций несколькими способами, которые позволили бы вам контролировать уровень управления из командной строки (и, следовательно, Дженкинса). Вы хотели бы пометить спецификации другими метаданными, например, безопасно ли работать для реального времени, может ли это длиться долгое время и т.д.