Як імітувати API REST?

Я працюю над новим проектом, який запитуватиме дані від стороннього API REST. Це подання спортивних даних у режимі реального часу, тому канал працює лише тоді, коли гра фактично відбувається.

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

Мій єдиний прийом - написати код, щоб самостійно імітувати гру, але це, здається, багато роботи. Як би ти підійшов до цього?

Це ідеальний випадок використання для макетного об’єкта . Існують глузуючі бібліотеки для кожної популярної мови. Ви хочете знущатися над об’єктом, який надає відповіді служби REST, щоб повернути тестові дані. Ви можете або генерувати тестові дані вручну, або збирати їх з попередніх дзвінків до живої системи.

Зачекайте, поки відбудеться гра. Захоплюйте кожну подію з каналу. Напишіть тренажер, який відтворює події у відповідний час. Voila, у вас є симулятор подачі з реальними даними.

Рекомендую написати власний тренажер. Ви можете використовувати його для тестування всіляких сценаріїв;

• Сервер приймає з'єднання, але не відповідає
• Час роботи сервера
• Сервер надсилає відповідь про сміття тощо ...

Коли я це робив у минулому, я використовував "спеціальні" значення у запитах запитів, щоб спонукати тренажер робити все, що мені потрібно. Це також дає змогу запускати тести на кінець, не виходячи за межі вашого середовища розробки.

Edit: Наприклад, якщо ваш проект Відправляє XML в службу 3 партії, запит може включати в себе , наприклад <value>50.00</value>. Симулятор можна закодувати (або, краще, налаштувати) так, щоб 50,00 => вибухнути, 60,00 => сміття, 70,00 => тісний зв’язок тощо. Ідея полягає в тому, що поведінка тренажера залежить від його введення, яким ви керуєте у кожному тестовому випадку.

Зважаючи на те, що, ймовірно, букмекер надає деякі зразкові дані (і це можна зберегти під час фази інтеграції), моя порада полягає в організації цих каналів таким чином:

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

Можливо, постачальник пропонує два типи оновлень: Push (POST) та Pull (GET).

У цей момент ви повинні

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

Керуйте розробкою та тестуванням

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

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

Особисто я би зробив простий сервер Perl або те саме, але з Nodejs. Що стосується введення даних, то буде достатнім таймер, який викликає офлайн-браузер ( CURL , WGET )

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

Це чудово працює:

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

У моєму сценарії я поєднав його з тестами для огірків у тому самому процесі, так що це було так:

1. Тестові запускання.
2. Він встановлює nockглузування HTTP для тестування сценарію.
3. Він завантажує сторінку у phantomjs через протокол Selenium.

Решта, як показано раніше в цьому пункті (тобто це трохи цикл, я як тестовий бігун доручаю phantomjs завантажити сторінку, яка пересилає мені всі запити назад, і я пересилаю їх до мережі; або перехоплюю їх, якщо це перевірений API).