Выделение сервиса из монолита — это не только архитектурная задача. Для QA это момент, когда привычные сценарии регресса перестают работать, а автотесты, которые годами жили в одном репозитории, требуют пересборки. В статье на Habr автор делится опытом: регресс при выкатке новой фичи ускорился в 30 раз, но автотесты пришлось переносить вручную, а не через Claude. Ниже — практический разбор, как подойти к тестированию нового микросервиса без иллюзий и лишней боли.

Что меняется для QA при выделении сервиса

Когда часть логики уезжает в отдельный сервис, меняются границы ответственности. Появляются сетевые вызовы, новые точки отказа, асинхронные взаимодействия и отдельные пайплайны деплоя. Тесты, которые раньше проверяли функцию целиком внутри монолита, теперь должны учитывать два и более компонента. Первый шаг — зафиксировать, какие сценарии остаются в монолите, какие уходят в новый сервис, а какие становятся интеграционными. Без этой карты любая автоматизация будет наугад.

Практичный приём: составьте матрицу «функция — компонент — тип теста». Для каждой функции определите, проверяется ли она юнит-тестами внутри сервиса, контрактными тестами на стыке или end-to-end через UI. Это помогает не дублировать проверки и не тащить в новый сервис лишние зависимости. Типичная ошибка — автоматически перенести все старые тесты «как есть», не пересмотрев их актуальность.

Перенос автотестов: вручную или с ИИ

Автор статьи сознательно переносил автотесты руками, а не через Claude. Причина проста: контекст. Старые тесты часто завязаны на внутренние моки, фикстуры и неочевидные зависимости, которые инструмент не восстановит без глубокого понимания домена. ИИ может ускорить рутину — сгенерировать каркас, переписать однотипные ассерты, — но решение о том, что именно тестировать в новом сервисе, остаётся за QA.

Критерии выбора подхода к переносу:

  • Сложность сценария. Если тест проверяет один метод с простыми входными данными — можно доверить генерацию ИИ и проверить результат. Если сценарий включает несколько сервисов, очереди и таймауты — только ручная переработка.
  • Наличие неявных зависимостей. Тесты с большим количеством моков и фикстур лучше переписать заново, чем адаптировать.
  • Критичность. Для платёжных и авторизационных сценариев ручной перенос с ревью обязателен.
  • Стоимость поддержки. Если тест после переноса станет хрупким, дешевле удалить его и заменить контрактной проверкой.

Пример: тест, который проверял расчёт скидки внутри монолита, после выделения сервиса стал интеграционным. Вместо мока базы данных появился HTTP-вызов. Простой перенос кода привёл бы к ложным падениям при недоступности сети. Правильное решение — разделить проверку на юнит-тест формулы и контрактный тест API.

Стратегия тестирования нового микросервиса

Начинайте с контрактов. Определите формат запросов и ответов, коды ошибок, таймауты и поведение при деградации. Контрактные тесты (например, на основе OpenAPI или Pact) дают быструю обратную связь и защищают от рассинхронизации между монолитом и сервисом. Дальше — юнит-тесты на бизнес-логику внутри сервиса и интеграционные проверки с реальными зависимостями в изолированном окружении.

Отдельно продумайте тестовые данные. В монолите часто использовалась одна база, а теперь у сервиса может быть своя схема. Нужны скрипты миграции, очистки и генерации данных. Если этого не сделать, тесты будут падать из-за грязного состояния. Ещё один пункт — наблюдаемость: логи, метрики и трассировка должны позволять QA быстро понять, на каком этапе упал сценарий.

Чек-лист для старта тестирования:

  • Согласовать с командой границы сервиса и список интеграционных точек.
  • Описать контракты API и зафиксировать их в тестах.
  • Подготовить тестовые окружения с изолированными данными.
  • Определить, какие старые автотесты переносятся, какие переписываются, а какие удаляются.
  • Настроить сбор логов и метрик для диагностики падений.

Типичные ошибки и как их избежать

Первая ошибка — пытаться сохранить 100% покрытие старыми тестами. При распиле монолита часть проверок теряет смысл. Вторая — игнорировать негативные сценарии на стыке сервисов: таймауты, повторные запросы, частичные отказы. Третья — автоматизировать всё подряд без приоритетов. Лучше иметь 20 стабильных контрактных тестов, чем 200 хрупких end-to-end, которые падают через раз.

Пример из практики: после выделения сервиса регресс ускорился в 30 раз, но только потому, что команда отказалась от тяжёлых сквозных сценариев в пользу контрактных и юнитов. Если бы все старые тесты перенесли механически, выигрыша бы не было. Вывод простой: тестирование микросервиса — это не про перенос, а про пересборку стратегии под новые границы. И начинать нужно с карты зависимостей и контрактов, а не с выбора инструмента для генерации кода.