После добавления большого числа end-to-end-тестов CI стал медленным, хотя покрытие выросло. Какое архитектурное решение восстановит быструю обратную связь?
Нужно перераспределить проверки по уровням тестовой пирамиды: основную часть сценариев перенести на быстрые модульные и интеграционные тесты, а end-to-end оставить для небольшого набора критических пользовательских потоков. Это сокращает время CI, сохраняя проверку поведения на разных уровнях.
Подход тестовой пирамиды появился как ответ на проблему дорогих и медленных сквозных проверок. Чем больше система проверяется через полный пользовательский сценарий, тем больше времени требуется на запуск, подготовку окружения и диагностику отказов.
Идея пирамиды состоит не в запрете end-to-end-тестов, а в распределении тестов по стоимости и области ответственности. Нижние уровни дают быструю локальную обратную связь, верхние подтверждают работоспособность системы как целого.
End-to-end-тест обычно проходит через несколько компонентов, базу данных, сеть, очереди или браузер. Поэтому его отказ может быть вызван дефектом приложения, проблемой окружения, тестовыми данными или внешней зависимостью, а диагностика занимает больше времени.
Если одинаковые бизнес-правила проверяются только на верхнем уровне, тестовый набор разрастается, CI становится узким местом, а разработчики получают результат слишком поздно. Полное удаление end-to-end-тестов тоже опасно: оно может скрыть ошибки интеграции компонентов и реальные проблемы пользовательского маршрута.
Сначала следует определить, какие свойства проверяет каждый сценарий. Чистые правила и преобразования лучше проверять модульными тестами, взаимодействие нескольких компонентов — интеграционными, а несколько наиболее важных сквозных потоков — end-to-end-тестами.
Переносить тест нужно не механически, а вместе с его проверяемым риском. Например, бизнес-правило можно надежно проверять на уровне сервиса, но факт корректной маршрутизации запроса через шлюз и авторизацию может требовать интеграционной или сквозной проверки.
Практическая стратегия обычно включает:
Важно не путать покрытие кода с покрытием риска. Сокращение числа end-to-end-тестов допустимо, если их сценарии заменены более быстрыми проверками там, где сохраняется тот же ожидаемый результат, а оставшиеся сквозные тесты покрывают ключевые пользовательские цепочки.
Компромисс состоит в том, что нижние уровни дают менее реалистичную проверку окружения, а верхние — более дорогую и менее локализованную диагностику. Поэтому границы между уровнями нужно поддерживать явно: интеграционные контракты, тестовые данные и ответственность компонентов не должны быть скрыты внутри большого сквозного сценария.
В интернет-магазине после добавления десятков сквозных сценариев проверка pull request стала занимать около часа. Команда рассматривала три варианта: увеличить число CI-агентов, отключить часть тестов или переработать набор.
Увеличение параллельности могло сократить календарное время, но повысило стоимость CI и не решило проблему сложной диагностики. Отключение тестов ускорило бы сборку, однако снизило бы контроль критических потоков. Команда выбрала переработку: проверки расчёта скидок и правил доставки перенесли на уровень сервиса, взаимодействие с базой и платежным адаптером сделали интеграционными, а в end-to-end оставили оформление заказа и оплату.
В результате быстрые проверки стали давать обратную связь раньше, а сквозной набор сохранил контроль ключевого пользовательского пути. При этом команда отдельно контролировала, чтобы перенос теста не убрал проверку нужной интеграционной границы.
Нет. Это эвристика для управления стоимостью и скоростью обратной связи, а не фиксированное количественное требование. В системе с небольшим числом компонентов, например в простом веб-приложении, доля сквозных тестов может быть выше; в распределённой системе их диагностика и поддержка обычно существенно дороже.
Модульный тест изолирует компонент и часто заменяет его зависимости тестовыми двойниками. Он может подтвердить правильность локальной логики, но не обнаружить несовместимость схем, неверный формат сообщения, ошибку конфигурации или неправильное взаимодействие реальных компонентов. Поэтому модульные тесты должны дополняться интеграционными проверками границ системы.
Нужно сравнить проверяемый риск, а не только текст сценария. Если тест подтверждает локальное бизнес-правило и не зависит от поведения нескольких реальных компонентов, его обычно можно перенести на уровень сервиса или модуля. Если же риск связан с маршрутизацией, сериализацией, авторизацией, совместимостью компонентов или пользовательским интерфейсом, часть проверки должна остаться на соответствующем интеграционном или сквозном уровне.