Давайте для начала вспомним, что же такое микросервис, а точнее микросервисная архитектура:
Микросервисная архитектура — вариант сервис-ориентированной архитектуры программного обеспечения, направленный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — микросервисов, получивший распространение в середине 2010-х годов в связи с развитием практик гибкой разработки и DevOps.
И определение E2E (end-to-end) тестирования:
E2E тестирование — вид тестирования, при котором бизнес-процессы тестируются от начала и до конца в условиях, аналогичных производственным.
В своей работе я имел опыт тестирования микросервисов и скажу, что всё весьма неоднозначно.
Недавно наткнулся на статью по этой теме:
https://chroniclesofapragmaticprogrammer.substack.com/p/end-to-end-testing-in-microservices
В ней автор делиться своими мыслями насчёт того, что качественно и быстро протестировать только одними E2E тестами микросервисы нельзя.
Давайте попробуем разобраться 👌
Для экономии вашего времени рассмотрим ключевые моменты статьи:
➡️ Тестирование является гарантией того, что продукт на выходе будет соответствовать ожиданиям и потребностям пользователей и бизнеса
➡️ Продукт тестируется в различных ситуациях, чтобы убедиться, что он справляется с реальными задачами
➡️ Тестирование существует не для того, чтобы препятствовать или замедлять разработку
➡️ Медленные, нестабильные и сложные в обслуживании E2E тесты могут стать серьёзной проблемой и вот почему:
🔸 при падении сложно разобраться, в чём действительно была проблема (где-то в микросервисе, их взаимодействии или ещё где-то)
🔸 долгое ожидание обратной связи
🔸 отсутствие уверенности в результатах из-за flaky (нестабильных) тестов
🔸 для обслуживания необходимо много ресурсов
🔸 задержка деплоя
🔸 низкая эффективность выявления багов
➡️ Вспоминаем пирамиду или кубок тестирования: E2E тестов не должно быть много
➡️ Очереди сообщений RabbitMQ или Kafka привносят определённые трудности
➡️ Не заменяйте критические части системы моками/стабами и прочими симуляциями, а также понимайте ограничения, которые они накладывают. В некоторых ситуациях симуляция может быть полезна
➡️ Одна команда не может выкатиться без фиксов тестов другой команды – это тормозит работу. Написание контрактных и интеграционных тестов должны помочь проверить функциональность сервиса и взаимодействие сервисов более изолированно
➡️ Контрактные тесты всё усложняют? Нет. Рассматривайте их как уменьшение нагрузки на E2E тесты и способ проверки связи между сервисами
➡️ Пишите контрактные тесты, даже если микросервисов пока ещё мало. В дальнейшем это поможет. И внедряйте постепенно, начиная с наиболее важных сервисов
➡️ Используйте комбинированный подход: контрактные, приёмочные тесты и E2E.
Приёмочные тесты предназначены для проверки того, соответствует ли система или функциональность бизнес-требованиям и ожиданиям заинтересованных сторон.
✅ Подводя итоги, автор говорит, что при неправильном использовании E2E тестов они могут создавать проблемы, особенно в сложных архитектурах.
✍ Основываясь на своём опыте хочу согласится в целом с идеями и мыслями автора.
Действительно, даже без микросервисов нужно опираться на пирамиду тестирования, пытаться избавиться от flaky тестов и ускорять прогоны тестов.
🧐 В тоже время меня смутил пример про подсчёт времени длительности тестов с пятью ручками у сервиса. В данный момент это не является проблемой, ведь можно запускать тесты в параллели в десятки-сотни потоков, что уменьшает длительность выполнения тестов в разы.
#микросервисы #тестирование #e2e
