Блог Томаша Фяйялковского о программировании
Самая важная трансформация для большинства организаций — дать людям и командам возможность выполнять творческую и качественную работу. Ключ к этому — крупномасштабные постепенные изменения. В последние годы сервисные архитектуры, особенно микросервисы, приобрели огромную популярность, однако подход к сквозному тестированию (E2E) зачастую остаётся прежним. Часто слышно, что тесты, проверяющие работу всей системы, жизненно необходимы при разработке программного обеспечения, особенно в распределённых архитектурах. Звучат утверждения вроде «Нужно доказать, что система работает как единое целое. Раньше у нас был монолит и E2E‑тесты; теперь у нас независимые микросервисы, значит E2E‑тесты ещё более необходимы». В этой статье под E2E‑тестами я понимаю тесты всей системы — то есть такие сценарии, которые требуют запуска нескольких сервисов. Поэтому, например, фронтенд‑тесты в браузере с подменённым бэкендом (моки, стабы и т. п.) к этой категории не относятся.
Переоценка важности тестов «всей системы» — признак мышления в духе монолита. Если требуется тестировать систему целиком, это означает, что ключевые свойства распределённой архитектуры, такие как независимость изменений и деплоев, не достигнуты. Независимость деплоя вообще заложена в определение микросервисов. На этом можно было бы закончить дискуссию, но стоит внимательнее рассмотреть негативные стороны E2E‑тестирования в контексте микросервисов. В сервисно‑ориентированной архитектуре E2E‑тесты несут не только известные проблемы стоимости, скорости, стабильности и сложности, описанные в «пирамиде тестирования», но и существенно влияют на рабочие процессы. Поскольку эти тесты проверяют работу между несколькими командами, нередко формируется отдельная команда тестировщиков, которая их разрабатывает и поддерживает. Такое решение плохо масштабируется и вводит задержки: работа проходит через несколько команд — от разработчиков через тестировщиков до деплоя/релиза.
В другом подходе ответственность за E2E‑тесты распределяют между всеми командами. Тогда типично происходят ситуации, когда изменение в одном сервисе вызывает падение тестов и блокирует деплой сервиса другой команды. В обеих конфигурациях обеспечение множества релизов в день становится проблематичным, а график публикаций уязвим для непредсказуемых задержек. Команды теряют независимость и вынуждены тратить больше времени на координацию. Введение первого E2E‑теста порождает целый набор вопросов: кто будет их поддерживать, как и где они будут запускаться, как обеспечить независимость команд и деплоев и т. д.
Потребность в E2E‑тестах обычно возникает по двум основным причинам. Первая — когда система в целом построена корректно, сервисы независимы, но менеджер мысленно застрял в монолитном подходе и не понимает концепции независимых сервисов с чёткими границами в форме контрактов. Страх за стабильность системы и нежелание брать на себя ответственность в случае сбоя тоже могут подталкивать к требованию «тестировать всё целиком». В таких случаях помогают обучение или смена менеджера; в крайних ситуациях — культурные изменения в компании. Вторая причина — собственно состояние архитектуры, когда элементы образуют распределённый монолит и тесно сцеплены между собой. Тогда стоит проанализировать контракты между сервисами: не стали ли E2E‑тесты следствием отказа от строгих контрактов в пользу рыхлых соглашений, применяются ли паттерны «X‑as‑a‑service» в потреблении API, использованы ли потребитель‑ориентированные контракты.
Отсутствие контрактов — это не только отсутствие описания эндпоинтов; оно проявляется в формулировках вроде «нужно запускать систему на предпродакшн‑или UAT‑окружении с продакшн‑данными n дней, потому что мы не можем предсказать все наборы данных и комбинации событий». Если вы всё же решаете применять E2E‑тесты, убедитесь, что они быстрые и стабильные — это само по себе серьёзная задача. Кроме того, введение первого такого теста существенно повлияет на всю систему: станет непросто решить, кто будет их поддерживать, и как они повлияют на рабочие процессы всех команд. Поэтому ограничьте их область только критическими частями системы и контролируйте их количество.
Как и документация не является требованием по своей природе, так и E2E‑тесты не являются обязательным требованием. Подумайте, какие риски вы хотите минимизировать и какие проблемы решить при помощи этих тестов. Как ещё подходить к этим задачам? Многое зависит от контекста, но во многих случаях можно обойтись без каких‑либо E2E‑тестов. Вопрос безопасного развёртывания независимых сервисов объёмный, поэтому здесь я не рассматриваю его полностью. В первую очередь определите границы сервисов через API‑контракты и тщательно тестируйте эти контракты. При проектировании сервисов стоит также решить, какие именно процессы требуют полного тестирования и почему. Выбор между оркестрацией и хореографией влияет на тестирование: обычно тестировать процесс, управляемый одним сервисом, проще, потому что тесты можно ограничить этим сервисом. Чтобы минимизировать риски, связанные с деплоем, рассмотрите практики, такие как blue‑green‑деплоймент и другие техники постепенного релиза.
В конечном счёте, если система действительно требует тестирования как единого целого, возможно, микросервисы — не лучший выбор, и монолит с монорепозиторием подойдёт лучше. Важно не застревать в мышлении монолита: монолит — это не только архитектура, это также способ мыслить о проблеме.
Блог «Programming Chi (или Qi)» посвящён скромным идеям, ошибкам и неудачам, с которыми автор сталкивается ежедневно; вместе с неудачами есть и множество успехов и элегантных решений, о которых он также надеется писать.
Новостной материал
Ведущие практики тестирования в эпоху микросервисов остаются предметом острой дискуссии: несмотря на широкое распространение сервис‑ориентированных архитектур, подход к сквозному (E2E) тестированию во многих организациях не изменился, что, по мнению экспертов, свидетельствует о продолжающемся «монолитном» мышлении внутри команд и менеджмента. Автор профессионального блога по программированию отмечает, что требование к тестированию «всей системы» нередко означает, что архитектурные цели распределённости и независимости сервисов не достигнуты.
По словам аналитиков, E2E‑тесты в среде микросервисов порождают не только традиционные сложности — высокие затраты, медлительность, нестабильность и усложнённую инфраструктуру тестирования — но и серьёзно влияют на рабочие процессы. Практика показывает две типичные модели: выделение отдельной команды тестирования для создания и поддержки E2E‑тестов либо распределение этой ответственности между всеми командами. Обе модели приводят к негативным последствиям: в первом случае — к узким местам и задержкам из‑за перекладывания работы между командами, во втором — к блокировкам релизов при изменениях в одном сервисе, которые ломают тесты других команд. Оба сценария делают частые многократные релизы в течение дня практически невозможными и лишают команды независимости.
Специалисты выделяют две главные причины, по которым организации настаивают на E2E‑тестах. Первая — это культурная проблема: менеджмент не принимает концепцию независимых сервисов с чёткими контрактами и боится отвечать за стабильность системы. Вторая — техническая: сама архитектура по сути представляет собой распределённый монолит, где отсутствуют строгие контракты и сервисы тесно связаны. В таких случаях E2E‑тесты используются как «заплатка» на проблему отсутствия контрактного подхода к API и взаимодействию сервисов.
Эксперты рекомендуют вместо массового внедрения E2E‑тестов сосредоточиться на определении и тестировании API‑контрактов, применять потребитель‑ориентированные контракты и анализировать, какие бизнес‑процессы действительно требуют полного тестирования. Выбор между оркестрацией и хореографией в системах с распределёнными процессами также влияет на стратегию тестирования: процессы, управляемые одним сервисом, легче покрывать локальными тестами. При необходимости всё‑системного теста специалисты советуют ограничивать его область критическими сценариями и добиваться высокой скорости и стабильности таких тестов.
Кроме того, для снижения рисков при деплое предлагаются практики постепенного релиза, такие как blue‑green‑деплоймент и другие техники, позволяющие минимизировать влияние изменений. Авторы обращают внимание: если система по‑прежнему требует тестирования как единого целого, возможно, изначальный выбор в пользу микросервисов следует пересмотреть в пользу монолита и монорепозитория. Общий вывод экспертов прост: внедрение E2E‑тестов в экосистему микросервисов должно быть осознанным и ограниченным, а критически важные элементы системы лучше защищать чёткими контрактами и локальными тестами, чтобы не подрывать независимость команд и скорость релизов.
