# run once, it create DB services with schemas
docker compose up -d postgres
# build and run tests
./gradlew clean build
./gradlew bootRun
# open in browser http://localhost:8080/swagger-ui.html
-
Проблемы интеграционного тестирования.
У нас есть много микросервисов и при изменении поведения в одном мы хотим гарантировать, что не нарушается функциональность других. Два подхода:- Развертывание микросервисов:
- требуется много ресурсов для прогона и в один момент времени возможен только один сценарий;
- на поднятие всех сервисов требуется много времени;
- очень сложно разбираться в ошибках.
- Мокировать внешние сервисы:
- при изменении протокола или поведения мы не можем быть уверены, что никто не отвалится.
- Развертывание микросервисов:
-
Contract driven development (CDD):
- Мы создаем описание нашего контракта на Producer, по этому контракту генерируются unit-тесты на контроллеры. Тем самым мы гарантируем, что на Producer контроллеры обрабатывают именно такое API.
- После этого описание заливается в nexus (или другое хранилище артефактов, возможно локальное) или в git.
- На стороне Consumer поднимается легковесный сервер wiremock, для него указывается файл json, предоставленный Producer, в котором описаны запросы и ответы.
-
Посмотрим, как это выглядит в действии.
Три сервиса: склад (Warehouse), заказы (Order), доставка (Delivery).- Warehouse публикует контракт:
- Получить информацию о всех вещах на складе
GET /items?page=\<page>&size=\<size>
- Зарезервировать заказ для пользователя
POST /items/take (body: { itemUids: [] })
- Получить информацию о вещи
GET /items/{itemUid}/state
- Выписать вещь со склада для доставки
POST /items/{itemUid}/checkout
- Получить информацию о всех вещах на складе
- Остальные сервисы на своей стороне реализуют этот контракт.
- На сервисах Orders и Delivery реализуем контракт и пишем тесты.
- Это все публикуем в gitlab и настраиваем зависимые сборки. Чтобы при изменении в сервисе Warehouse контракт публиковался и вызывалась переборка и прогон тестов на других сервисах/
- Изменяем название полей, поведение методов, добавляем или удаляем поля в запрос и ответ. Любуемся что тесты на других сервисах упали.
- Warehouse публикует контракт:
-
Есть еще один очень насущный вопрос в мире микросервисов – как бы отдать пользователю актуальную удобную документацию. Все, конечно, знают про OpenAPI, но часто требуют наличие какой-то бумажной или офлайн-документации. Для этого существует rest-docs. Описание API генерируется по тестам на API, более того, во время работы проверяется, что все поля в запросе и ответе описаны в документированном описании. Получается, что при описании в restdocs мы имеем практически описание контракта.
Пример модуля, где фигурирует описание restdocs, показать как по нему сгенерировать groovy dsl контракт.