Что такое микросервисы и какие преимущества они дают
Что проверяют
Тестировщика спрашивают про микросервисы, чтобы понять, как меняется ваша стратегия проверки, когда система перестаёт быть одним процессом. Умеете ли вы проверять контракт, а не только экран, и понимаете ли, почему часть дефектов тут воспроизводится через раз.
Как отвечать
Сначала суть: независимые сервисы со своей областью и своим хранилищем, связанные контрактами. Из этого следует ваша работа.
Пирамида меняет форму. Основной объём переносится на тесты одного сервиса с подменёнными соседями и на контрактные тесты, где ожидания потребителя проверяются против реального поставщика. Сквозных сценариев оставляют немного, только критичные бизнес-пути: на десяти сервисах они становятся долгими и нестабильными.
Отдельно проверяйте то, чего не было в монолите: обратную совместимость версии API, поведение при недоступности соседа и при таймауте, идемпотентность повторной доставки сообщения, порядок и дубли в очереди, консистентность, которая наступает не сразу. Тестовые данные заводятся через API владельца, а не прямой вставкой в чужую базу. Для разбора дефекта нужен сквозной идентификатор запроса в логах всех участников.
Где спотыкаются
Тестируют только через интерфейс пользователя. Половина логики живёт в обмене между сервисами, и дефект контракта такой проверкой ловится поздно, уже на общем стенде, когда чинить его дороже всего.
Заводят баг «данные не обновились», не разобравшись, что обновление асинхронное. Правильный тест ждёт наступления состояния с разумным ограничением по времени и проверяет, что оно вообще наступает, а не дёргает проверку сразу после запроса.
Требуют полностью поднятого окружения для любой проверки. Из-за этого тесты идут часами и краснеют по чужим причинам, а команда перестаёт им верить. Подмена соседей заглушками и контрактные тесты возвращают быстрый и честный сигнал.