Что такое пирамида тестирования

Пирамида тестирования отвечает не на вопрос "какие тесты существуют", а на вопрос "где выгоднее проверить конкретное поведение". Чем ниже уровень, тем тест быстрее, дешевле и точнее показывает место поломки. Чем выше уровень, тем он ближе к реальному пользовательскому сценарию, но дороже в запуске и поддержке.

Для frontend это особенно важно. Один и тот же баг можно искать через E2E-сценарий в браузере, через тест формы с мокнутым API или через unit-тест валидатора. Если выбрать слишком высокий уровень, команда получает медленный CI и flaky-падения. Если выбрать слишком низкий, можно не заметить ошибку в связке компонентов.

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

Допустим, в приложении есть форма промокода. У нее есть расчет скидки, валидация поля, запрос к API и сообщение пользователю.

export function applyDiscount(total: number, percent: number) {
  if (percent < 0 || percent > 100) {
    throw new Error("Invalid discount");
  }

  return total - total * (percent / 100);
}

Такую функцию разумно проверить unit-тестом. Для нее не нужен браузер, React и реальный сервер. Если расчет сломается, unit-тест быстро покажет точную причину.

А вот сценарий "пользователь вводит промокод, видит ошибку от API и кнопка остается доступной" лучше проверять integration-тестом компонента или формы. В этом тесте важно проверить не только текст ошибки, но и отсутствие второго запроса при повторном клике, снятие loading-состояния и понятный фокус после ошибки. Так безопаснее, чем ловить все только через E2E: полный браузерный сценарий медленнее и хуже покажет, где именно сломалась форма.

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

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

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

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

На интервью лучше сказать так:

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

Пирамида тестирования помогает писать тесты, которым команда доверяет. Если тест быстро падает рядом с причиной ошибки, разработчик исправляет баг быстрее. Если тест долго запускается, часто flaky и показывает только "что-то сломалось", он хуже помогает релизу.

Хороший ответ на интервью состоит из трех частей: объясните уровни, назовите trade-off каждого уровня и покажите, как вы выбираете уровень во frontend-задаче. Так ответ звучит не как определение из учебника, а как рабочий подход.