E2E-тестирование: что это

E2E-тест воспроизводит реальный сценарий использования продукта от начала до конца. Не «проверить функцию расчёта скидки», а «пользователь зашёл, положил товар в корзину, применил промокод, оплатил и получил письмо с чеком» — и всё это на работающей системе с настоящими интерфейсом, бэкендом и базой.

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

Фронтенд отправляет данные в одном формате, бэкенд ждёт в другом; оплата проходит, но письмо не уходит; регистрация работает, а вход сразу после неё — нет. Такие дефекты живут на границах между компонентами, и увидеть их можно, только пройдя сценарий целиком.

Отсюда роль E2E: это финальная проверка, что ключевые бизнес-сценарии действительно работают так, как их пройдёт живой пользователь. Не как задумано в спецификации, не как работает в изоляции, а как есть в собранной системе.

E2E не существует сам по себе — он верхний этаж многоуровневой проверки. Чтобы понять его роль, полезно видеть всю картину.

Главная мысль, которую пропускают команды, увлёкшиеся сквозными тестами. Пирамида тестирования — модель, которая говорит, в какой пропорции держать уровни: широкое основание из быстрых юнит-тестов, меньше интеграционных посередине и совсем немного E2E на вершине.

Причина такой формы — в цене E2E. Сквозной тест:

• Медленный. Он поднимает всю систему и проходит длинный сценарий; сотня E2E-тестов гоняется не минуты, а десятки минут или часы.
• Хрупкий. Он завязан на интерфейс и данные, поэтому ломается от любой мелочи — переехавшая кнопка, изменившийся текст, просроченный тестовый аккаунт. Такие «падения» не про баг в продукте, а про сам тест.
• Дорогой в поддержке. Каждый такой тест нужно чинить каждый раз, когда меняется то, за что он цепляется, — а в живом продукте это происходит постоянно.

Перевёрнутая пирамида — когда почти всё проверяется через медленные сквозные тесты, а быстрых юнит-тестов мало — классическая беда. Прогон длится вечность, тормозит релизы, и половина падений оказывается ложной. Здоровое правило: то, что можно проверить дешёвым юнит-тестом, проверяют юнит-тестом; E2E приберегают для сценариев, которые иначе не покрыть, — сквозных бизнес-путей через всю систему.

Сквозные тесты бывают двух видов, и различие практическое, а не терминологическое.

Горизонтальный E2E проходит полный пользовательский сценарий через несколько систем на одном уровне — так, как его видит пользователь. Пример: клиент оформляет заказ в интернет-магазине — от каталога через корзину и оплату до подтверждения. Это то, что чаще всего имеют в виду под E2E.

Вертикальный E2E проверяет один сценарий насквозь по слоям архитектуры — от интерфейса через API и бизнес-логику до базы данных, — не обязательно как целостный пользовательский путь. Его применяют для критичных технических сценариев, которые важно проверить сверху донизу, даже если пользователь их отдельно не «проходит».

На практике продукту нужны в основном горизонтальные сценарии — они отражают реальные бизнес-пути и приносят больше всего пользы. Вертикальные подключают точечно, для особо ответственных участков.

Раз каждый E2E-тест дорог, выбор сценариев — вопрос экономики, а не полноты. Разумный отбор строится на двух вопросах: критичен ли путь для бизнеса и нельзя ли проверить его дешевле.

Через E2E стоит гонять ключевые сквозные сценарии, поломка которых бьёт по деньгам: регистрация и вход, путь «выбор товара → оплата → подтверждение», ключевая функция продукта от начала до конца. Это те несколько путей, ради которых продукт существует; их проверяют целиком и регулярно.

Через E2E не стоит проверять то, что закрывается дешевле: логику расчётов (юнит-тест), поведение отдельного модуля (интеграционный), валидацию каждого поля формы, все возможные комбинации ввода. Гонять сотню вариаций через сквозной тест — способ получить медленный, хрупкий и бесполезно раздутый набор.

E2E-тесты почти всегда автоматизируют — вручную прогонять длинные сценарии на каждый релиз нереально. Инструменты зависят от платформы: для веба в 2026 году это чаще всего Playwright и Cypress (современные, быстрые), а также ветеран Selenium; для мобильных приложений — Appium. Выбор инструмента вторичен; первичны две вещи, на которых спотыкаются чаще всего.

Тестовые данные и окружение. Сквозному тесту нужна работающая среда с предсказуемыми данными: тестовый аккаунт, тестовая оплата, база в известном состоянии. Если данные «уплывают» между прогонами, тест падает не из-за бага, а из-за окружения. Стабильное тестовое окружение — половина успеха E2E, и именно её обычно недооценивают.

Хрупкость и «флаки». Тест, завязанный на конкретные элементы интерфейса, ломается при любой правке вёрстки. Лечится это устойчивыми привязками (не к тексту кнопки, а к стабильным идентификаторам) и дисциплиной: «мигающий» тест либо чинят сразу, либо убирают, потому что тесту, который падает через раз, перестают верить — и тогда он хуже, чем его отсутствие.

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

Строить перевёрнутую пирамиду. Покрывать сквозными тестами то, что должно проверяться юнитами, — прямой путь к прогону на часы и куче ложных падений. E2E дополняет нижние уровни, а не заменяет их.

Гнаться за покрытием. Стремление проверить через E2E все ветки и комбинации превращает набор в неподъёмный и хрупкий. Сквозные тесты — про несколько критичных путей, а не про полноту; полноту дают дешёвые уровни ниже.

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