9-5 · Глава 9 · 4 мин. чтения

End-to-End тесты: когда они помогают, а когда только замедляют

Разбираемся, когда end-to-end тесты действительно нужны, а когда они становятся узким местом. Практические советы по организации E2E-тестирования в CI/CD пайплайне.

End-to-End тесты: когда они помогают, а когда только замедляют

У вас есть юнит-тесты, проверяющие каждую функцию. Интеграционные тесты, верифицирующие запросы к базе данных. Контрактные тесты, гарантирующие, что API-договоренности соблюдаются. Пайплайн зелёный. Всё выглядит отлично.

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

Каждый компонент работал изолированно. Вместе они отказали.

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

Что на самом деле делают End-to-End тесты

End-to-end тест запускает всю вашу систему так, как это делал бы реальный пользователь. Приложение стартует. В базе данных — настоящие данные. Внешние API вызываются по-настоящему. Браузер или мобильный клиент выполняют реальные действия.

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

Уверенность от прохождения end-to-end тестов реальна. Если ваши критические сценарии проходят, вы можете быть достаточно уверены, что пользователи не упрутся в стену на основных функциях. Но эта уверенность дорого обходится.

Реальная цена End-to-End тестов

Один end-to-end тест может занимать несколько минут. Умножьте это на десятки сценариев — и вы получите часы времени пайплайна. И это в лучшем случае.

End-to-end тесты падают по причинам, не имеющим отношения к вашему коду. Таймаут из-за медленного тестового окружения. Несогласованные тестовые данные, оставшиеся от предыдущего запуска. Истощение пула соединений с базой данных из-за параллельных тестов. Внешнее API, ограничивающее количество тестовых запросов.

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

Вот почему нельзя бросать end-to-end тесты на всё подряд. Нужно быть хирургически точным в выборе того, что тестировать и как запускать эти тесты.

Когда End-to-End тесты действительно необходимы

End-to-end тесты нужны, когда сценарий невозможно проверить никаким другим типом тестов. Обычно это сценарии, которые пересекают несколько компонентов в рамках одного пользовательского пути.

Платёжный сценарий — классический пример. Юнит-тесты могут проверить логику расчёта цены. Интеграционные тесты — что заказ сохраняется в базу данных. Контрактные тесты — формат запроса к платёжному шлюзу. Но ни один из них не может доказать, что реальный пользователь действительно сможет завершить покупку от начала до конца. Только end-to-end тест способен на это.

Другой критерий — риск. Если поломка функции нанесёт значительный ущерб, она заслуживает end-to-end теста. Вход в систему — хороший кандидат, потому что если он сломается, никто не сможет пользоваться приложением. Оформление заказа — ещё один, так как оно напрямую влияет на выручку.

С другой стороны, страница профиля пользователя, которая редко меняется, или админская функция, используемая тремя людьми внутри компании, вероятно, могут быть покрыты интеграционными тестами. Риск низок, и затраты на end-to-end тест не оправданы.

Как запускать End-to-End тесты, не замедляя всех

Как только вы определили сценарии, которые действительно нуждаются в end-to-end покрытии, следующая задача — запускать их в пайплайне, не заставляя разработчиков ждать вечность.

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

Запускайте тесты параллельно. Если у вас десять тестов, каждый из которых занимает три минуты, запуск их последовательно добавит тридцать минут к вашему пайплайну. Запуск параллельно может сократить это время до трёх минут, при условии, что у вас достаточно инфраструктуры для поддержки конкурентных окружений. Это инвестиция, которую стоит сделать.

Выделите end-to-end тесты в отдельный этап пайплайна. Не смешивайте их с юнит-тестами или интеграционными тестами. Сначала запускайте быстрые тесты и давайте разработчикам быструю обратную связь. Запускайте медленные end-to-end тесты только после того, как всё остальное прошло. Таким образом, разработчик узнает о падении юнит-теста через несколько минут, не дожидаясь end-to-end набора.

Запускайте подмножество на каждый коммит, полный набор — периодически. Вам не нужно запускать каждый end-to-end тест на каждое изменение кода. Запускайте самые критичные на каждый коммит. Полный набор запускайте ночью или перед релизом в продакшн. Это балансирует скорость и покрытие.

Вот пример конфигурации YAML пайплайна, который запускает end-to-end тесты только по ночному расписанию или при ручном запуске, сохраняя основной пайплайн на коммиты быстрым:

# azure-pipelines-e2e.yml
# Отдельный пайплайн для end-to-end тестов

trigger: none  # Не запускать на каждый коммит

schedules:
- cron: '0 2 * * *'  # Запуск каждую ночь в 2:00
  displayName: Nightly end-to-end tests
  branches:
    include:
    - main

resources:
  pipelines:
  - pipeline: mainBuild
    source: main-ci
    trigger:
      branches:
        include:
        - main

jobs:
- job: e2e_tests
  displayName: 'Run End-to-End Tests'
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: |
      echo "Starting end-to-end test suite..."
      npm run test:e2e
    displayName: 'Execute E2E tests'

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

Практический чеклист

Прежде чем добавить новый end-to-end тест, задайте себе эти вопросы:

Можно ли проверить этот сценарий более быстрым типом теста?
Если этот сценарий сломается, сколько пользователей пострадает и насколько серьёзно?
Это критический пользовательский путь или сценарий «было бы неплохо»?
Можем ли мы запустить этот тест параллельно с другими?
Устойчив ли тест к проблемам окружения?

Если ответ на первый вопрос «да» — не пишите end-to-end тест. Если риск низок — не пишите. Если это не критический путь — не пишите.

Вывод

End-to-end тесты дают наибольшую уверенность в том, что ваша система работает как единое целое. Но эта уверенность дорого обходится во времени, инфраструктуре и поддержке. Используйте их только для самых важных сценариев. Запускайте их с умом, чтобы они не стали узким местом, из-за которого ваша команда будет ненавидеть пайплайн.

Несколько хорошо выбранных end-to-end тестов, которые стабильно проходят, стоят больше, чем сотня нестабильных тестов, которым никто не доверяет.