Содержание

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

Пирамида тестирования — это модель, описывающая, в каких пропорциях стоит писать тесты разных уровней. Её предложил Майк Кон, и с тех пор она стала отраслевым ориентиром.

Идея проста: тесты делятся на уровни, и чем ниже уровень — тем таких тестов должно быть больше.

        /\
       /e2e\        мало, медленные, дорогие
      /------\
     / integ. \     средне
    /----------\
   /    unit    \   много, быстрые, дешёвые
  /--------------\
  • Unit-тесты проверяют отдельную функцию или класс в изоляции. Они выполняются за миллисекунды и не зависят от базы данных, сети или файловой системы.
  • Интеграционные тесты проверяют, как несколько компонентов работают вместе: например, репозиторий с реальной базой или два сервиса через HTTP.
  • E2E-тесты (end-to-end) прогоняют сценарий целиком, как это сделал бы пользователь: открыть страницу, заполнить форму, нажать кнопку, увидеть результат.

Почему именно такие пропорции

Каждый уровень платит свою цену по трём осям: скорость, стоимость поддержки и стабильность.

Скорость. Тысяча unit-тестов отрабатывает за пару секунд. Тысяча e2e-тестов может крутиться полчаса. Чем дольше прогон, тем реже разработчики его запускают — и тем позже ловят ошибки.

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

Стабильность. Unit-тест детерминирован: на одних входных данных всегда один результат. E2E зависит от десятка факторов — таймингов, состояния базы, сети — поэтому склонен к плавающим падениям (flaky-тестам).

Отсюда вывод: основу проверки логики выгоднее держать на дешёвом и быстром уровне, а дорогие e2e оставить для нескольких по-настоящему критичных пользовательских сценариев.

Что пирамида НЕ означает

Частое заблуждение — воспринимать пирамиду как «e2e-тесты не нужны». Нужны. Только их роль — проверить, что система собрана воедино и ключевой путь пользователя работает, а не покрывать каждую ветку условия.

Второе заблуждение — что цифры на уровнях абсолютны. Пирамида про порядок величины, а не про точные числа. Если у вас 800 unit, 120 интеграционных и 15 e2e — пропорции здоровые, даже если в книжке нарисовано иначе.

Антипаттерн 1: перевёрнутая пирамида

Самый болезненный случай — когда основная масса тестов сосредоточена наверху.

  \--------------/
   \    e2e     /     ОЧЕНЬ много
    \----------/
     \ integ. /
      \------/
       \unit/         мало
        \/

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

Антипаттерн 2: «рожок мороженого»

Ещё хуже — когда поверх перевёрнутой пирамиды громоздится ручное тестирование.

   ручное тестирование    <- основная масса
  \--------------------/
   \       e2e        /
    \----------------/
     \   integ.     /
      \-----unit---/

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

Как держать пирамиду здоровой

Несколько практических ориентиров:

  1. Новую логику покрывайте unit-тестами сразу. Чем ближе тест к моменту написания кода, тем он дешевле.
  2. Спрашивайте: можно ли проверить это уровнем ниже? Если бизнес-правило проверяется unit-тестом, не дублируйте его в e2e.
  3. E2e — только для критичных путей. Логин, оформление заказа, оплата. Не «все возможные комбинации фильтров».
  4. Следите не за процентом покрытия, а за обратной связью. Хорошая пирамида даёт ответ «сломалось или нет» за секунды, а не за полчаса.

Современный взгляд: testing trophy

Кент Доддс предложил альтернативу — «трофей тестирования», где центр тяжести смещён на интеграционные тесты. Это разумно для фронтенда и стеков, где изоляция модулей даёт мало уверенности, а связки компонентов важнее.

Но это не отмена пирамиды, а её настройка под контекст. Базовый принцип неизменен: дешёвых и быстрых тестов должно быть много, дорогих и медленных — мало. Конкретный профиль зависит от того, где в вашей системе живёт реальный риск.

Итог

Пирамида тестирования — не догма с точными числами, а напоминание о компромиссе между скоростью, стоимостью и стабильностью. Держите основу на быстрых unit-тестах, добавляйте интеграционные там, где важны связки, и берегите e2e для нескольких ключевых сценариев. Тогда тесты будут помогать, а не превращаться в обузу, которую все боятся запускать.

Поделиться: