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

Перехват и подмена

page.route перехватывает запросы по шаблону URL; route.fulfill отдаёт свой ответ вместо настоящего.

await page.route("**/api/rates", (route) =>
  route.fulfill({
    status: 200,
    json: { usd: 92.5 },
  }),
);

Теперь запрос курса валют не уходит наружу, а получает фиксированный ответ. Можно и пропустить запрос с модификацией (route.continue), и сымитировать ошибку (status: 500) — чтобы проверить, как продукт показывает сбой.

Что мокать

Мок оправдан для зависимостей, которые в e2e только мешают:

  • Внешние сервисы — платёжный шлюз, карты, сторонние API: они нестабильны, платны, имеют тестовые режимы; мок делает тест детерминированным.
  • Редкие/тяжёлые состояния — сымитировать ответ, который иначе трудно воспроизвести (ошибка сервера, пустой список, таймаут).
await page.route("**/api/payment", (route) =>
  route.fulfill({ status: 200, json: { status: "paid" } }),
);

Чего НЕ мокать

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

Правило баланса: критический путь идёт через реальный backend (ради этого e2e и существует), а мокается только то, что по краям — внешнее, нестабильное, дорогое. Если хочется замокать собственный API на главном сценарии — скорее всего, тест надо опустить ниже по пирамиде.

Контроль ради детерминизма

Даже не подменяя, сеть полезно наблюдать — дождаться нужного ответа перед проверкой (ожидание условия), а не времени. Это убирает гонки между запросом и утверждением — частый источник флаки.

Где это в UCP

Контроль сети в e2e — это про баланс: мокать внешнее и нестабильное ради детерминизма, но гонять критический путь через настоящий backend, иначе сквозной тест перестаёт быть сквозным. Это та же граница, что мок портов vs реальная база в backend-тестах: подменяй то, что мешает, проверяй то, ради чего тест. Для продукт-инженера это стабильные e2e, которые всё ещё проверяют настоящую интеграцию продукта; а что делать с остающейся нестабильностью — борьба с flaky.