Что такое E2E: пройти кассу глазами клиента

Сцена · пройти весь путь клиента

Все предыдущие уроки мы разбирали кассу по частям: чистый домен проверяли примерами и property, границы подменяли слоями. Но клиент не знает про твой домен и твои слои. Он открывает браузер, вводит почту, жмёт кнопку, проводит платёж и смотрит на баланс. Всё, что между, для него один чёрный ящик.

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

Карта урока · что заберёшь

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

Раздел 1 · что такое E2E и чем он дорог

Идея словами

E2E (end to end, “из конца в конец”) проверяет приложение целиком: браузер, сеть, сервер, база. Ничего не подменяется. В этом его сила и его цена.

Сравни охват трёх уровней на одном действии “провести платёж”:

юнит         applyPayment(account, payment)         микросекунды, всё в памяти
интеграция   POST /payments -> реальный SQL          миллисекунды, БД настоящая
E2E          клик в браузере -> сервер -> БД -> UI    секунды, всё настоящее

Чем выше уровень, тем больше настоящего и тем больше уверенности, что “оно правда работает у клиента”. И тем дороже: E2E медленный (поднять браузер и сервер), хрупкий (зависит от вёрстки, таймингов, сети) и тяжёлый в поддержке. Поэтому на вершине пирамиды их мало.

Картинка · охват против цены

        ▲ уверенность "работает у клиента"
        │
   E2E  │  ███           мало, дорого, медленно
        │  ███
  интегр│  ██████        больше, дешевле
        │  ██████
   юнит │  ████████████  много, дёшево, быстро
        └──────────────────────────────────▶ количество

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

Шаг 1 · первый E2E Kassa

Критический сценарий кассы это деньги: вошёл, провёл платёж, баланс уменьшился. Пишем его на Playwright:

// e2e/specs/payment.spec.ts
import { DashboardPage } from '../pages/DashboardPage';
import { LoginPage } from '../pages/LoginPage';
import { expect, test } from '../fixtures';

test('логин, платёж, баланс уменьшается', async ({ page }) => {
  const login = new LoginPage(page);
  const dashboard = new DashboardPage(page);
  const email = `pay-${Date.now()}@batschool.dev`;

  await login.open();
  await login.login(email);

  await dashboard.expectBalance('1000.00');

  await dashboard.pay('100.00');

  await dashboard.expectBalance('900.00');
  await expect(page.getByTestId('history')).toContainText('списано 100.00');
});

Тест не знает ни про applyPayment, ни про слои, ни про SQL. Он делает ровно то, что делает человек, и проверяет ровно то, что человек видит. LoginPage и DashboardPage это Page Object, куда спрятаны селекторы, их разберём в уроке 18.

Когда код пишет агент

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

Что взять с собой

• E2E проверяет всё приложение целиком, ничего не подменяя;
• он самый честный и самый дорогой, поэтому его мало;
• один E2E это путь клиента, а не отдельная ветка логики.