Лучшие практики тестирования микросервисов

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

В этой статье рассматриваются принципы разработки и лучшие практики тестирования ПО для архитектуры микросервисов.

Содержание

• Что такое микросервисы

• Это сложно!

• Кто хочет, тот добьётся

• Выводы

Что такое микросервисы

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

В своей книге «Микросервисы. Паттерны разработки и рефакторинга» Крис Ричардсон говорит о трех аспектах определения архитектуры микросервисов, подсказанных трехмерной моделью расширяемости Мартина Эббота и Майкла Фишера – кубом масштабирования. Он предполагает три способа масштабирования приложения:

• Масштабирование по оси X или горизонтальное масштабирование – это выполнение многочисленных идентичных экземпляров приложения на фоне работы балансировщика нагрузки.

• Масштабирование по оси Y или функциональная декомпозиция означает декомпозицию монолитных приложений до отдельных слабо сопряжённых элементов с ограниченным контекстом.

• Масштабирование по оси Z или разбиение данных – масштабирование приложения на основе разбиения данных, при котором каждый экземпляр отвечает за подмножество данных.

Ключевыми факторами, стимулирующими использование архитектуры микросервисов, являются модульность и масштабируемость. Сложность архитектуры растет по мере увеличения числа микросервисов, добавления асинхронной передачи сообщений, кэширования и т.д.

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

Это сложно!

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

В то время как предложенная Майком Коном пирамида тестирования широко используется в качестве лучшей практики при построении стратегии тестирования микросервисов, ее реализация по-прежнему далека от идеала. Наиболее частая проблема возникает на этапе разработки теста – реализация соответствующего набора тестов в правильном месте. ✅

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

По отдельности все прекрасно, но окончательный результат дает только интеграционный тест

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

Заглушки – это прекрасно, но на них нельзя полагаться

Чтобы минимизировать проблемы с интеграционными тестами, команды зачастую начинают использовать большее количество тестовых двойников. Несмотря на то, что таким образом устраняется зависимость от других команд, использование имитаций и заглушек часто становится чрезмерным и приводит к сложностям в управлении.

Кроме того, во многих случаях отсутствует обратная связь, позволяющая проверить достоверность тестовых заглушек. Реализация интеграционного сервиса работает не так, как заглушки, что создает проблемы для сквозного тестирования.

Разрабатывать то, что надо, или разрабатывать как надо?

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

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

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

Я знаю, что пошло не так, но понятия не имею, где это случилось

Зачастую тесты не дают возможности отследить основную причину проблемы. Во многих случаях очень сложно собрать логи приложений и тестовые отчеты в единой визуализации в качестве свидетельства неудачного тестирования, что делает обратную связь неполной. Поиск и нахождение основной причины проблемы требуют дополнительных усилий.

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

Наша тестовая среда не является точной копией среды эксплуатации

По сравнению с монолитными системами микросервисы проще тестируются изолированно благодаря своему исполнению – они имеют меньший размер и более узкую направленность. Однако когда нам необходимо развернуть новую тестовую среду, это превращается в кошмар.

Для этого необходимо развернуть множество сервисов и баз данных, запустить новую систему обмена сообщениями, балансировщик нагрузки, сервисный шлюз и многое другое. Если у команды не хватает возможностей для развертывания тестовой среды по требованию, велика вероятность выпустить из виду некоторые аспекты до того момента, когда код окажется на этапе опытной или промышленной эксплуатации.

Кто хочет, тот добьётся

Да, реализовать эффективную стратегию тестирования микросервисов сложно, но все-таки возможно. Сегодняшние лидеры мнений в области технологий возлагают большие надежды на архитектуру микросервисов. По этой теме в интернете можно найти сотни конкретных примеров с разбором. Вот что я нашел