Начальный ~15 мин чтения

Пирамида тестов: стратегия и культура

Урок 1 из 5 в курсе Тестирование backend-приложений

Пирамида тестов: стратегия и культура

пирамида тестов описывает оптимальное соотношение unit, интеграционных и e2e тестов — много быстрых unit, меньше медленных e2e

Почему это важно: неправильная стратегия тестирования (только e2e или только unit) замедляет разработку; пирамида даёт максимальный confidence при минимальных затратах

Главная идея

unit тесты быстры и дёшевы; интеграционные проверяют взаимодействие компонентов; e2e тесты медленны и ломаются часто

Как это выглядит на практике

  1. Unit тесты: тестируем одну функцию изолированно. 100ms на весь suite из 1000 тестов.
  2. Интеграционные: тестируем controller + БД. Нужна тестовая БД; медленнее, но проверяют интеграцию.
  3. E2E: запускаем реальный браузер, кликаем, проверяем. Минуты на прогон; ломаются при изменении UI.
  4. Принцип: если что-то можно проверить unit-тестом — не нужен интеграционный.
  5. CI: unit тесты на каждый коммит; e2e — перед релизом или в отдельном pipeline.

Что происходит под капотом

  • Test runner выполняет тесты и сообщает о результатах (RSpec, pytest, JUnit, Go testing).
  • Code coverage: процент строк/веток, покрытых тестами. 100% coverage ≠ хорошие тесты.
  • Test isolation: каждый тест независим; порядок выполнения не должен влиять на результат.
  • Mutation testing: инструмент меняет код и проверяет, падают ли тесты — оценивает качество тестов.

Типичные ошибки и заблуждения

  • Ошибка: 100% code coverage = хорошо протестированный код. Coverage проверяет выполнение строк, не корректность поведения.
  • Ошибка: больше тестов — лучше. Плохие тесты хуже, чем их отсутствие: они замедляют рефакторинг и дают ложное чувство безопасности.
  • Ошибка: тесты замедляют разработку. На коротком горизонте — да; на длинном — ускоряют за счёт безопасного рефакторинга.
  • Ошибка: e2e тесты заменяют unit. E2E медленные, ломкие, сложно диагностировать причину падения.

Ключевые выводы

  • Много unit тестов, меньше интеграционных, мало e2e — пирамида.
  • Тест должен падать по одной конкретной причине.
  • Code coverage — индикатор, не цель.
  • Быстрые тесты = частые прогоны = быстрый feedback.

Термины урока

Unit test: тест одного изолированного компонента (функции, метода, класса).
Integration test: тест взаимодействия нескольких компонентов (API + БД).
E2E test: тест полного пользовательского сценария через UI.
Test coverage: процент кода, исполняемого тестами.
Test runner: инструмент запуска и отчёта тестов (RSpec, pytest, Jest).

Связь с работой backend-разработчика

Правило: если рефакторинг кода требует переписывания тестов — тесты слишком привязаны к реализации. Тестируй поведение (что делает), не реализацию (как делает).

Мини-разбор реальной ситуации

Команда из 5 человек имеет 500 e2e тестов и 20 unit. CI-прогон занимает 45 минут; разработчики перестают запускать тесты локально. Инверсия: 400 unit + 80 интеграционных + 20 e2e. Прогон: 3 минуты. Частота прогонов: каждый коммит.

Что запомнить

  • Пирамида: много unit, меньше интеграционных, мало e2e.
  • Тестируй поведение, не реализацию.
  • Быстрый тест = тест, который запускают.

Итог

Правильная стратегия тестирования — инвестиция в скорость разработки. Пирамида даёт максимальный confidence при минимальном времени прогона.