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

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

Что такое e2e

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коротко

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

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

  • Настройка Playwright — как поднять e2e с нуля.
  • Flakiness: нестабильные тесты — почему тесты иногда падают без причины и как с этим жить.