Как смоделировать REST API?

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

Хотя сторонние поставщики предоставляют хорошую документацию (XSD и т. Д.), У них нет возможности имитировать происходящее в игре, и поэтому для тестирования кода, написанного мной на этом API, мне придется подождать, пока не произойдет настоящая игра.

Единственное, что я могу сделать, - это написать код для симуляции игры, но это похоже на большую работу. Как бы вы подошли к этому?

Это идеальный вариант использования для фиктивного объекта . Есть библиотеки для насмешек для каждого популярного языка. Вы хотели бы смоделировать объект, который предоставляет ответы службы REST для возврата тестовых данных. Вы можете либо вручную сгенерировать тестовые данные, либо собрать их по предыдущим вызовам в действующей системе.

Подождите, пока игра не произойдет. Захватывать каждое событие из ленты. Напишите симулятор, который воспроизводит события в подходящее время. Вуаля, у вас есть симулятор корма с реальными данными.

Я рекомендую написать свой собственный симулятор. Вы можете использовать его для тестирования всевозможных сценариев;

• Сервер принимает соединение, но не отвечает
• Тайм-аут сервера
• Сервер отправляет обратно мусорный ответ и т. Д ...

Когда я делал это в прошлом, я использовал «специальные» значения в сообщениях запроса, чтобы предложить симулятору сделать то, что мне нужно. Это также позволяет запускать сквозные тесты, не выходя за пределы среды разработки.

Edit: Например, если ваш проект Отправляет XML в службу 3 партии, запрос может включать в себя , например <value>50.00</value>. Симулятор может быть закодирован (или, лучше, сконфигурирован) так, чтобы 50.00 => взорваться, 60.00 => мусор, 70.00 => закрыть соединение и так далее. Идея состоит в том, что поведение симулятора зависит от его входных данных, которые вы контролируете в каждом тестовом примере.

Учитывая, что, вероятно, букмекер предоставляет некоторые образцы данных (и их можно сохранить на этапе интеграции), я советую организовать эти каналы следующим образом:

• Список событий
• Обновления для запланированных событий
• Обновления шансов
• Результаты

Возможно, провайдер предлагает 2 типа обновлений: Push (POST) и Pull (GET).

На данный момент вы должны

1. Создайте простой сервер, который будет обрабатывать только запросы GET, чтобы ваши программисты могли разрабатывать алгоритмы.
2. Создайте автоматизацию для управления подачей одной и той же информации и, следовательно, для вашей системы.

Управлять разработкой и тестированием

Не вдаваясь в детали используемой технологии, вы получаете мини-сервер , который отвечает только на 4 URL-адреса (или те, которые необходимы в зависимости от того, что предлагает поставщик), и услугу мини-push .

Очень хорошая вещь, которую нужно иметь в виду при работе с «мини-сервером», - это обработчики протокола HTTP. Создать сервер на 80-м порту очень просто, и проблема решается. Вы должны быть уверены, что вставили всю информацию в ответы GET, как это делает провайдер (это позволит избежать проблем при запуске в производство).

Лично я бы сделал простой Perl-сервер или такой же, но с Nodejs. Что касается внедрения данных, будет достаточно таймера, который вызывает автономный браузер ( CURL , WGET )

Я смоделировал REST API, используя комбинацию cucumberjs, phantomjs с настройкой прокси-сервера на 127.0.0.1 и перехватом процесса node.js с помощью http-proxyи nockтам. CucumberJS не важная часть, вы можете написать тестовый сценарий любым способом, остальное - ключ к симуляции. Он может имитировать просто с помощью match-request-return-data, но вы также можете фильтровать по шаблонам и перехватывать функцию обратного вызова для получения ответа, так что вы можете моделировать до любого уровня детализации, который вам нужен (в крайнем случае, заканчивая полный демо-сервер, но вы можете сделать это постепенно).

Работает красиво:

1. Phantomjs запрашивает URI.
2. Запрос идет на прокси-сервер по 127.0.0.1:port.
3. Ваш процесс node.js прозрачно проксирует его, используя http-proxy. Так что любая «нормальная» загрузка (страницы, изображения) работает.
4. Если вы решите перехватить некоторые запросы (в основном API), вы будете использовать nockих.

В моем сценарии я объединил его с js-тестами cucumber в одном и том же процессе, так что получилось так:

1. Тестовые прогоны.
2. Он устанавливает nockHTTP-макет для тестируемого сценария.
3. Загружает страницу в фантомах по протоколу Selenium.

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