Запускаем веб-сервис, и разработка интерфейса упёрлась в ещё не готовый серверный слой — до его выхода остаётся минимум пара недель. Чтобы не терять время, хочу заказать отдельный сервер-имитатор: он берёт нашу спецификацию OpenAPI и подменяет собой боевой сервис, выдавая стабильные, заранее прописанные ответы на каждый задокументированный вызов. Тогда клиентские приложения можно спокойно собирать и показывать заказчику уже сейчас, а после готовности настоящего сервера достаточно будет поменять адрес подключения. Подчеркну: речь именно о мокинге и заглушках, а не о шлюзе или наборе автотестов — проксирование, разбор прав доступа и проверочные библиотеки не нужны, нужны правдоподобные искусственные ответы.
Ожидаю, что сервис самостоятельно прочитает описание и соберёт черновые примеры данных из объявленных схем, но при этом даст возможность вручную переопределять любой вызов — задавать своё тело ответа с привязкой к адресу, HTTP-методу и коду результата. Отдельно важна имитация нештатных условий: регулируемая пауза перед ответом, принудительная выдача ошибок вроде 400, 401, 404, 429 и 500, а также переключение ответа по заголовку или параметру запроса, чтобы проверять и нормальную работу, и реакцию интерфейса на сбои. Наборы ответов должны храниться в простых файлах под контролем версий и подхватываться на лету, без остановки сервиса. Плюс небольшой конфиг с общими настройками паузы и частоты ошибок по умолчанию.
В итоге нужен один сервис, который поднимается локально одной командой и упаковывается в контейнер для общего тестового окружения. Приложите короткую инструкцию и несколько примеров использования.
— Чтение описания OpenAPI и автосоздание примеров ответов для каждого вызова
— Ручная замена ответов по адресу, методу и коду через редактируемые файлы
— Имитация пауз, тайм-аутов и принудительных ошибок по запросу
— Подхват изменённых файлов на лету без перезапуска
— Локальный старт одной командой и контейнер для тестового стенда
Ожидаю, что сервис самостоятельно прочитает описание и соберёт черновые примеры данных из объявленных схем, но при этом даст возможность вручную переопределять любой вызов — задавать своё тело ответа с привязкой к адресу, HTTP-методу и коду результата. Отдельно важна имитация нештатных условий: регулируемая пауза перед ответом, принудительная выдача ошибок вроде 400, 401, 404, 429 и 500, а также переключение ответа по заголовку или параметру запроса, чтобы проверять и нормальную работу, и реакцию интерфейса на сбои. Наборы ответов должны храниться в простых файлах под контролем версий и подхватываться на лету, без остановки сервиса. Плюс небольшой конфиг с общими настройками паузы и частоты ошибок по умолчанию.
В итоге нужен один сервис, который поднимается локально одной командой и упаковывается в контейнер для общего тестового окружения. Приложите короткую инструкцию и несколько примеров использования.
— Чтение описания OpenAPI и автосоздание примеров ответов для каждого вызова
— Ручная замена ответов по адресу, методу и коду через редактируемые файлы
— Имитация пауз, тайм-аутов и принудительных ошибок по запросу
— Подхват изменённых файлов на лету без перезапуска
— Локальный старт одной командой и контейнер для тестового стенда
