ФАЗА 48. E2E Выбор покрытия

Несколько сквозных путей подтверждают систему целиком

Critical paths · Pyramid · Confidence

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

обновлено 9 ноября 2026·~5 мин чтения

1. E2E идёт через работающую систему

1 / 5

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

  • Сборка развёрнута.
  • Браузер настоящий.
  • Путь имеет бизнес-результат.
User actionПриложение целикомВидимый итог

2. Пирамида ограничивает число E2E

2 / 5

Быстрые unit и component проверки покрывают ветки, сквозные тесты подтверждают немногие критические пути без повторения всех комбинаций.

  • Скорость сохраняется.
  • Дублирование ограничено.
  • Каждый уровень имеет вопрос.
E2EIntegration и componentUnit

3. Критический путь выбирается по ущербу

3 / 5

Регистрация, заказ, оплата и доступ к деньгам получают E2E, косметическая страница не требует дорогого прогона.

  • Пользовательская ценность высока.
  • Стыки влияют на исход.
  • Ошибка блокирует бизнес.
Кандидат E2EВлияниеСтыкиЧастота

4. Некоторые ошибки видны только вместе

4 / 5

Сериализация, реальные права, миграции, CORS и несовпадение UI с API проявляются на границах, которые заглушки скрывают.

  • Настоящая база важна.
  • Контракт проверяется эффектом.
  • Интеграционная ошибка локализуется.
Каждый модуль зелёныйСистема падает на стыке

5. Выбор пересматривается по риску и стоимости

5 / 5

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

  • Цена поддержки видна.
  • Flaky лечится.
  • Покрытие связано с инцидентами.
РискE2E сценарийДоказательство и решение

Когда нужен e2e

← назад к разделу

Приложение покрыто юнит-тестами, все они зелёные. Но пользователь жмёт «Оплатить» — и ничего не происходит. Юниты проверяли каждую часть в отдельности, а проблема оказалась на стыке: фронт ждал одно поле, бэк вернул другое. E2E-тест нашёл бы это сразу.

Что такое e2e

E2E-тест (end-to-end, сквозной) управляет реальным браузером как пользователь: открывает страницу, кликает, заполняет форму, ждёт ответа. За кликом стоит настоящий фронтенд, настоящие запросы, настоящий бэкенд. Это проверка собранного продукта, а не его отдельных кусков.

Отсюда и цена: e2e медленнее юнит-теста в сотни раз, зависит от сети и таймингов, может сломаться от любого изменения интерфейса. Это не недостаток — это плата за то, что он проверяет систему целиком.

Пирамида тестов

Из соотношения скорости и охвата следует простое правило — пирамида:

  • Снизу, широко — юнит-тесты. Быстрые, дешёвые, их много. Проверяют отдельный класс или функцию.
  • Посередине — интеграционные. Проверяют взаимодействие нескольких частей: контроллер + база, компонент + API.
  • Наверху, узко — e2e. Немного, только самое важное.
e2e 5–15 сквозных путей интеграционные стыки нескольких частей юнит-тесты много, быстро, дёшево

Снизу много дешёвых юнитов, наверху немного сквозных тестов: перевёрнутая пирамида даёт многочасовой прогон и недоверие к красному.

Перевёрнутая пирамида — частая ошибка. Когда e2e-тестов много, а юнитов мало, прогон превращается в многочасовое ожидание, нестабильные тесты становятся нормой, и команда перестаёт им доверять. E2E немного именно потому, что каждый дорог.

Что покрывать e2e

E2E берут на критические сквозные пути — сценарии, провал которых ломает продукт для пользователя и бизнеса.

В интернет-магазине это, например: регистрация → поиск товара → добавление в корзину → оформление заказа → оплата. Один-два таких пути через весь стек — вот цель e2e.

Что не стоит покрывать сквозными:

  • Детали отображения — правильнее проверять компонентными тестами: быстрее и точнее.
  • Бизнес-правила и ветвления — это область юнит-тестов. Все возможные скидки, проверки баланса, ограничения — проверяй там, где не нужен браузер.
  • Все возможные комбинации — комбинаторику проверяют ниже по пирамиде, e2e берёт один типичный путь.

Правило: если сценарий можно проверить дешевле — проверь там. E2E оставляют для того, что проверяется только целиком.

Какие баги ловит только e2e

Юниты проверяют части в изоляции. Интеграционные тесты проверяют отдельные соединения. Но есть целый класс проблем, которые проявляются только когда всё собрано вместе:

  • Фронт ждёт поле userId, бэк возвращает user_id — оба теста зелёные, авторизация не работает.
  • После оплаты пользователя должны перенаправить в личный кабинет, но редирект ведёт на 404.
  • Токен успешно создаётся, но не передаётся в следующий защищённый запрос.

Каждый кусок по отдельности работает, а вместе путь сломан. Это зона e2e — стыки между системами, которые видны только в собранном продукте.

Как выбрать, что покрывать

Ответьте на три вопроса:

Если этот сценарий сломается — бизнес потеряет деньги или пользователей прямо сейчас? Регистрация, оплата, ключевое действие продукта — да. Настройки уведомлений — скорее нет.

Можно ли это проверить дешевле? Если логика живёт в одной функции — это юнит. Если нужна только база — это интеграционный. Если нужен браузер и весь стек — это e2e.

Это регрессия, которая будет повторяться? Если конкретный сценарий ломался несколько раз — это кандидат в e2e.

Типичный результат: 5–15 e2e-тестов на продукт среднего размера. Не сотни.

Коротко

  • E2E управляет реальным браузером и проверяет собранный продукт — медленно, но охватывает стыки, которые не видят изолированные тесты.
  • Пирамида тестов: внизу много юнитов, вверху мало e2e — это осознанное соотношение цены и пользы.
  • E2E берут на критические сквозные пути: регистрация, оплата, ключевое действие продукта.
  • Детали отображения, бизнес-правила, комбинаторику — проверяй ниже по пирамиде.
  • Главный класс багов, который ловит e2e — стыки: каждая часть зелёная, а вместе путь не работает.
  • Типичный объём — 5–15 сквозных сценариев, не сотни.

Что почитать дальше