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

Updated Jul 2026

За рамками учебной диаграммы

Каждый QA-инженер видел тестовую пирамиду. Немногие команды реализуют её правильно. Разрыв между «я знаю, что такое пирамида» и «я могу проанализировать тестовый набор моей команды по отношению к пирамиде и дать стратегические рекомендации» — это разрыв между мышлением младшего и старшего QA-специалиста.

Этот раздел охватывает основные модели форм тестирования, когда каждая из них применима, как выявлять анти-паттерны и как провести аудит распределения тестов в вашем проекте.

Классическая тестовая пирамида (Mike Cohn, 2009)

            /  E2E  \            Few, slow, expensive
           /  Tests  \
          /───────────\
         / Integration \         Some, moderate speed
        /    Tests      \
       /─────────────────\
      /    Unit Tests     \      Many, fast, cheap
     /─────────────────────\

Принцип

• Много модульных тестов в основании: быстрые, дешёвые, изолированные, запускаются при каждом коммите
• Меньше интеграционных тестов в середине: проверяют взаимодействия компонентов, умеренная скорость
• Немного сквозных тестов на вершине: медленные, дорогие, хрупкие, но проверяют полный пользовательский путь

Почему это всё ещё актуально

Пирамида кодирует истину о соотношении затрат и выгод, которая не изменилась с 2009 года:

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

Когда классическая пирамида работает лучше всего

• Бэкенд-сервисы со сложной бизнес-логикой (расчётные движки, обработка данных)
• Библиотеки и фреймворки, где API-контракты важнее, чем UI
• Микросервисы, где каждый сервис имеет чёткие границы и контракты
• Зрелые кодовые базы с высокой дисциплиной модульного тестирования

Тестовый трофей (Kent C. Dodds, 2018)

            /  E2E  \
           /─────────\
          / Integration \        ← Most tests here
         /    Tests      \
        /─────────────────\
       /   Unit    /  Static \
      /───────────/───────────\

Принцип

Трофей инвертирует акценты для приложений с преобладанием фронтенда:

• Статический анализ (TypeScript, ESLint) ловит самые дешёвые баги при нулевых затратах на выполнение
• Модульные тесты для чистой логики и утилит
• Интеграционные тесты — «золотая середина» — они тестируют компоненты так, как с ними взаимодействуют пользователи, обеспечивая лучшее соотношение уверенности к стоимости
• Немного E2E-тестов только для критических путей

Почему Додс предложил это

Во фронтенд-приложениях модульное тестирование отдельных React-компонентов в изоляции (с моками всех зависимостей) даёт низкую уверенность, потому что реальный риск — во взаимодействии компонентов. Интеграционный тест, который рендерит форму, заполняет поля и отправляет её, тестирует реальный пользовательский опыт гораздо лучше, чем 50 изолированных модульных тестов компонентов.

Когда тестовый трофей работает лучше всего

• Приложения с преобладанием фронтенда (React, Vue, Angular SPA)
• Приложения с простой бизнес-логикой, но сложными UI-взаимодействиями
• Команды, использующие библиотеки компонентов, где отдельные компоненты уже протестированы upstream
• Проекты, где TypeScript или статический анализ ловят многие потенциальные баги

Тестовый ромб и соты

Тестовый ромб

         /  E2E  \
        /─────────\
       / Integration \        ← Widest: most tests
      /    Tests      \
     /─────────────────\
      \  Unit Tests   /       ← Narrower
       \─────────────/

Ромб естественно возникает в микросервисных архитектурах, где:

• Отдельные сервисы имеют тонкую бизнес-логику (узкий слой модульных тестов)
• Сложность кроется в межсервисном взаимодействии (широкий слой интеграции)
• E2E-тесты покрывают критические кросс-сервисные пути

Соты (модель Spotify)

       ┌──────────────────┐
       │  Integrated Tests │    Few
       ├──────────────────┤
       │  Integration      │    ← Most effort here
       │  Tests            │
       ├──────────────────┤
       │  Implementation   │    Few
       │  Detail Tests     │
       └──────────────────┘

Модель сот Spotify различает:

• Тесты деталей реализации: тесты, которые ломаются при рефакторинге без изменения поведения (часто перетестированы)
• Интеграционные тесты: тесты, которые проверяют поведение на границах сервисов (оптимальная зона)
• Интегрированные тесты: тесты, которые пересекают несколько сервисов (дорогие, используйте экономно)

Анти-паттерны: когда форма неправильная

Перевёрнутая пирамида (конус мороженого)

     /───────────────────────\
    /       E2E Tests         \      Many, slow
   /───────────────────────────\
    \   Integration Tests    /       Some
     \─────────────────────/
      \   Unit Tests      /          Few or none
       \─────────────────/
        \  Manual Tests /            Lots
         \─────────────/

Симптомы:

• Тестовый набор выполняется часами
• Большинство тестов нестабильны, потому что зависят от всего стека
• Разработчики не запускают тесты локально, потому что они слишком медленные
• Локализация багов плохая — тест падает, но вы не знаете, какой компонент виноват
• Добавление новой функциональности требует обновления десятков E2E-тестов

Основная причина: Команда писала E2E-тесты первыми (или вместо) модульных тестов, часто потому что QA была единственной командой, писавшей тесты.

Решение:

1. Временно заморозьте создание E2E-тестов
2. Определите бизнес-логику под каждым E2E-тестом и перенесите её в модульные тесты
3. Замените E2E-тесты, проверяющие интеграционную логику, интеграционными тестами на уровне API
4. Оставьте только E2E-тесты, которые проверяют критические пользовательские пути от начала до конца

Песочные часы

      /  E2E Tests  \          Many
     /───────────────\
          |     |              Few integration tests
     \───────────────/
      \ Unit Tests  /          Many
       \───────────/

Симптомы:

• Модульные тесты проходят, а E2E-тесты падают — но никто не знает почему, потому что интеграционный слой не протестирован
• Баги концентрируются на границах сервисов (API-контракты, запросы к БД, форматы сообщений)
• Модульные тесты с большим количеством моков дают ложную уверенность (тесты проходят, но реальная интеграция сломана)

Основная причина: Команда тестирует крайности (изолированные единицы и полные пути) но пропускает середину (как компоненты реально взаимодействуют).

Решение: Добавьте интеграционные тесты на каждой границе сервиса. Тестируйте реальные API-вызовы, запросы к базе данных и форматы сообщений, а не их замоканные версии.

Сопоставление текущего тестового набора с пирамидой

Шаг 1: Инвентаризация тестов

Категоризируйте каждый тест в вашем наборе:

Test Inventory -- ShopFlow Project
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Unit tests:          412  (68%)  │████████████████████  │
Integration tests:    89  (15%)  │████                  │
E2E tests:           104  (17%)  │█████                 │
                    ─────
Total:               605

Execution time:
  Unit:          42 seconds
  Integration:   3 minutes 18 seconds
  E2E:          28 minutes 45 seconds
  Total:        32 minutes 45 seconds

E2E tests are 17% of the count but 88% of the execution time.

Шаг 2: Определите форму

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

Шаг 3: Анализ пробелов

Шаг 4: Рекомендации

На основе этого анализа:

1. Инструменты администрирования: Перенесите тестовое покрытие вниз. Напишите модульные тесты для бизнес-логики администрирования. Это сейчас «конус мороженого» для данной области функциональности.
2. Аутентификация: Добавьте интеграционные тесты для границы аутентификация-сессия. E2E-тесты покрывают это, но не могут точно указать на проблему.
3. Поиск: Добавьте интеграционные тесты для взаимодействия поиска с базой данных. 20% интеграционного покрытия — это опасно мало для высоконагруженной функции.

Анализ стоимости: затраты по типам тестов

Модель стоимости

Сравнение ROI

Предположим, баг в потоке оформления заказа, который можно поймать на любом уровне:

Unit test:
  Write: 20 min, Run: 0.5s, Maintain: 5 min/month, Debug on fail: 5 min
  Annual cost: ~2 hours

Integration test:
  Write: 45 min, Run: 5s, Maintain: 15 min/month, Debug on fail: 15 min
  Annual cost: ~4 hours

E2E test:
  Write: 2 hours, Run: 2 min, Maintain: 45 min/month, Debug on fail: 45 min
  Annual cost: ~12 hours

E2E-тест стоит в 6 раз дороже в годовом исчислении, чем модульный тест. Если баг можно поймать на уровне модульного теста, E2E-тест — это пустая трата ресурсов. Но если баг именно во взаимодействии страницы оформления заказа с платёжным API, только интеграционный или E2E-тест его обнаружит. Ключ — в соответствии уровня теста типу риска.

Практическое упражнение: аудит распределения тестов вашего проекта

Шаги упражнения

1. Подсчитайте тесты по типам. Используйте вывод тестового раннера или структуру директорий.

# Example for a JavaScript project
echo "Unit: $(find src -name '*.test.ts' | wc -l)"
echo "Integration: $(find tests/integration -name '*.test.ts' | wc -l)"
echo "E2E: $(find tests/e2e -name '*.spec.ts' | wc -l)"

2. Измерьте время выполнения по типам. Запустите каждый тестовый набор отдельно и запишите время.

3. Рассчитайте проценты. Какой процент ваших тестов на каждом уровне? Какой процент времени выполнения на каждом уровне?

4. Определите форму. Это пирамида? Трофей? Ромб? Конус мороженого? Песочные часы?

5. Сравните с идеалом. Исходя из типа вашего продукта (SaaS, мобильное, API и т.д.), какая модель подходит лучше всего?

6. Перечислите пробелы. У каких функций неправильное распределение тестов? Где вы переинвестируете в дорогие типы тестов?

7. Предложите 3 изменения. На основе анализа определите 3 конкретных действия для улучшения распределения тестов (например, «Конвертировать 10 E2E-тестов для инструментов администрирования в модульные тесты, добавить 5 интеграционных тестов для взаимодействия поиска с базой данных»).

Практическое упражнение

1. Проведите аудит, описанный выше, на вашем текущем проекте и нарисуйте форму вашего тестового набора
2. Определите 3 самых дорогих E2E-теста (по времени выполнения + поддержке) и определите, можно ли их заменить более дешёвыми типами тестов
3. Найдите одну область функциональности, которая покрыта только E2E-тестами, и напишите 3 модульных теста, покрывающих ту же бизнес-логику
4. Рассчитайте общее время выполнения вашего тестового набора по уровням тестов. Если E2E-тесты занимают более 80% времени, создайте план по переносу покрытия вниз
5. Представьте аудит тестовой пирамиды вашей команде и предложите 3 конкретных улучшения