Стратегия тестирования: пишите тесты, не много, но в основном интеграционные

Автоматизированное тестирование помогает создавать надёжные приложения. Хорошая стратегия даёт уверенность в качестве продукта без лишних затрат времени.

Зачем нужны тесты

Написание тестов кажется дополнительной работой. Но правильно настроенное тестирование экономит время в долгосроке.

Проще найти ошибку локально, чем получать звонки в 2 часа ночи из-за поломки на продакшене.

Главное: время на тесты окупается при поддержке и развитии проекта.

Статический анализ и автоматические тесты

Инструменты вроде TypeScript и ESLint отлавливают часть ошибок. Но даже строгая типизация не проверяет бизнес-логику — для этого нужны тесты.

Почему 100% покрытие — плохая идея

Требование полного покрытия кода часто вредит. После 70% наступает убывающая отдача: вы тестируете тривиальный код без логики, замедляете команду и усложняете рефакторинг.

Исключение: публичные библиотеки, где поломка затронет чужие проекты.

Пирамида тестирования против трофея

Классическая пирамида

Традиционная модель строится так (Unit → Integration → E2E):

• Unit-тесты — быстрые и дешёвые, но дают мало уверенности
• Интеграционные тесты — баланс скорости и надёжности
• E2E-тесты — медленные и дорогие, но покрывают реальные сценарии

Модель «Трофей тестирования»

С появлением новых инструментов подход изменился:

• Статический анализ (TypeScript, ESLint) — основа
• Интеграционные тесты — большая часть покрытия
• Unit-тесты — только для сложной изолированной логики
• E2E-тесты — критические пользовательские пути

Почему интеграционные тесты работают лучше

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

Меньше моков — больше реальности

Правила для интеграционного подхода:

• Не мокайте всё подряд — моки убирают уверенность в интеграции
• Реальные данные вместо mocks — кроме критичных операций (отправка email, списание денег)

Что тестировать в первую очередь

Задача — понимать, что тестировать и как получать реальную уверенность, а не иллюзию безопасности от проверки деталей реализации.

Четыре принципа:

1. Тестируйте поведение, а не реализацию — при рефакторинге тесты не должны ломаться
2. Фокус на интеграции — проверяйте совместную работу компонентов
3. Разумное покрытие — не гонитесь за 100% любой ценой
4. Критические сценарии — E2E-тесты для главных пользовательских путей

Видео

Итоги

Эффективное тестирование — это качество сценариев, а не количество тестов. Интеграционные тесты дают лучший ROI, проверяя реальное взаимодействие компонентов.

Комбинация статического анализа, интеграционных и E2E-тестов создаёт систему контроля, которая экономит время и ресурсы.

---

Оригинал: https://kentcdodds.com/blog/write-tests