Работали ли с микросервисами

Что проверяют

Понимаете ли вы, что меняется в тестировании при переходе от единого приложения к набору сервисов.

Как отвечать

Расскажите не про архитектуру вообще, а про то, что это значит для проверки.

Что усложняется:

• сквозной сценарий проходит через несколько сервисов. Поднять их все для теста дорого, а поддерживать такой стенд ещё дороже. Отсюда правило: сквозных проверок мало, только критичные пути;
• согласованность в конечном счёте. Действие выполнено, а результат появится через секунду или через минуту. Проверка сразу после действия даёт ложное падение, поэтому нужны ожидания с условием, а они же главный источник нестабильности;
• данные разложены по разным базам: подготовка состояния перестаёт быть одним запросом;
• отладка: без общего идентификатора запроса и распределённой трассировки непонятно, на каком участке всё сломалось.

Что появляется нового:

• контрактное тестирование: потребитель описывает ожидания к API, поставщик проверяет их у себя. Так совместимость ловится без поднятия обеих систем, и это главный ответ на разрастание сквозных тестов;
• проверка отказоустойчивости: что происходит, если сосед недоступен или отвечает медленно. Корректная деградация вместо ошибки на весь экран;
• идемпотентность обработчиков: повторная доставка сообщения не должна создавать дубль. Проверяется отправкой одного и того же события дважды;
• обратная совместимость версий: старый потребитель должен продолжать работать после выкатки новой версии поставщика.

Инструменты: клиент очереди для просмотра сообщений, интерфейс кластера для логов и состояния подов, трассировка, заглушки внешних сервисов.

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

Где спотыкаются

Переносят подход единого приложения и строят гору сквозных тестов.

Проверяют результат сразу после действия при асинхронной обработке.

Не знают про контрактное тестирование.

Не проверяют поведение при недоступности зависимости.