Что такое end to end тесты

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

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

На интервью можно ответить так: E2E тест проверяет не внутреннюю реализацию, а пользовательский сценарий целиком и результат, который важен пользователю.

Unit тест дешевый и быстрый. Он хорошо подходит для функций, хуков, форматтеров, редьюсеров и других небольших частей кода. Если сломалась функция расчета скидки, unit тест быстро покажет причину.

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

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

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

import { expect, test } from "@playwright/test";

test("user can sign in", async ({ page }) => {
  await page.goto("/login");

  await page.getByLabel("Email").fill("user@example.com");
  await page.getByLabel("Password").fill("correct-password");
  await page.getByRole("button", { name: "Sign in" }).click();

  await expect(page).toHaveURL(/dashboard/);
  await expect(page.getByRole("heading", { name: "Dashboard" })).toBeVisible();
});

Важный момент: тест ищет элементы по label, role и видимому результату. Это ближе к действиям пользователя и обычно стабильнее, чем поиск по CSS-классам. Если кнопка переедет в другую часть формы, но сценарий останется рабочим, тест не должен падать без причины.

Плохой вариант для такого сценария: искать .btn-primary, нажимать первую кнопку на странице и ждать wait(5000). Это ломается после редизайна, маскирует race condition и замедляет CI. Надежнее ждать конкретное состояние: переход на dashboard, исчезновение loader, видимый заголовок или сообщение об ошибке.

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

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

Для frontend особенно важны гонки вокруг сетевых запросов. Например, пользователь дважды нажал submit, первый запрос завершился позже второго, а UI показал устаревший результат. Хороший E2E или integration тест проверяет disabled состояние кнопки, loader, отмену или игнорирование старого ответа и понятное сообщение при ошибке.

Можно назвать Playwright, Cypress и Selenium. Но не сводите ответ к списку инструментов. Вопрос обычно проверяет понимание подхода: что именно проверяет E2E, почему эти тесты дорогие и как сделать их полезными.

Можно сформулировать так:

Я бы использовал E2E для критичных сценариев, где важно проверить приложение глазами пользователя. Например, логин, оформление заказа или создание заявки. Для стабильности я бы выбирал селекторы по роли, label или test id, готовил тестовые данные отдельно и не заменял E2E тестами все unit проверки.

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

Для frontend-разработчика E2E тесты особенно полезны перед релизом, потому что многие поломки появляются на стыке слоев. Компонент может быть написан правильно, API-клиент тоже, но вместе они ломаются из-за неправильного URL, CORS, авторизации, формата ответа, состояния localStorage или редиректа.

Практический минимум для важного сценария: проверить успешный путь, состояние загрузки, ошибку API, отсутствие двойной отправки и доступность основных элементов через label или role. Если приложение работает с внешними данными, полезно проверить, что опасная строка выводится как текст, а не как HTML. Иначе E2E может пропустить XSS-риск в реальном UI.

При этом E2E не должен превращаться в тест всего подряд. Если проверять каждую подсказку в форме через браузерный сценарий, тесты станут медленными. Лучше вынести детальную валидацию в unit или component тесты, а E2E оставить для ответа на вопрос: может ли пользователь успешно завершить важную задачу.