Легко ли тестировать микросервисную систему
Что проверяют
Понимаете ли вы, где в микросервисах живёт сложность тестирования: не в отдельном сервисе, а на границах между ними. Честный ответ «нет, не легко» здесь правильный, но за ним ждут стратегию. Следом обычно спрашивают, как вы проверяете, что изменение API одного сервиса не сломало соседей.
Как отвечать
Отдельный сервис тестировать проще, чем монолит: он маленький и с явными границами. Трудности начинаются на стыках: сеть, версии контрактов, асинхронные сообщения, согласованность в конечном счёте. Ответ стоит строить по уровням:
- юнит-тесты: xUnit или NUnit, зависимости подменяются через Moq или NSubstitute. Их больше всего, они проверяют доменную логику;
- интеграционные тесты сервиса:
WebApplicationFactory<TProgram>поднимает приложение в памяти, настоящие PostgreSQL, RabbitMQ или Kafka даёт Testcontainers, а чужие HTTP-сервисы заменяет WireMock.Net; - контрактные тесты: Pact (PactNet) фиксирует ожидания потребителя, и поставщик проверяет себя по ним в своём CI. Это главный ответ на вопрос, как не сломать соседа без общего стенда;
- асинхронное взаимодействие: если шина на MassTransit, её тестовый harness позволяет проверить, что сообщение опубликовано и обработано;
- E2E: несколько сценариев на критичные пользовательские пути, не больше;
- наблюдаемость: сквозные трассы через OpenTelemetry и корреляционный идентификатор в логах, иначе падение в цепочке из пяти сервисов не расследовать.
Хорошо добавить, что тестируемость закладывается архитектурой: сервис, который нельзя поднять без десятка соседей, плохо спроектирован, а не плохо протестирован.
Где спотыкаются
Опираются только на E2E на общем стенде. Там постоянно что-то развёрнуто не той версии, тесты краснеют по чужим причинам, и команда перестаёт им верить.
Используют провайдер EF Core InMemory вместо базы. Он не проверяет ограничения, не поддерживает транзакции и SQL, поэтому зелёные тесты ничего не говорят о работе с настоящей СУБД.
Проверяют асинхронный результат через Thread.Sleep. Тест становится и медленным, и нестабильным. Нужен опрос с таймаутом или ожидание события из harness.