Сообщить об ошибкеКороткий ответ
Стратегию стоит строить как пирамиду с основанием из быстрых unit-тестов бизнес-логики, средним слоем интеграционных тестов на границах с БД и внешними сервисами, и тонким верхним слоем e2e-тестов критичных пользовательских сценариев — конкретные пропорции и границы между слоями зависят от критичности сервиса, зрелости команды и стоимости инцидентов.
Как это работает подробнее
Каждый уровень тестовой пирамиды ловит свой класс ошибок: unit-тесты — ошибки в логике при минимальной стоимости и максимальной скорости; интеграционные — несовместимость с реальной БД, сериализацией, внешними контрактами; e2e — поломки в связке всех компонентов и инфраструктуры, но ценой медленного и более хрупкого прогона.
Сравнение
- Компромисс. Больше unit-тестов — быстрая обратная связь и низкая стоимость поддержки, но риск пропустить ошибки интеграции. Больше интеграционных/e2e — выше уверенность в реальном поведении системы, но дороже в поддержке, медленнее CI и больше flaky-тестов. Критерий выбора: критичность сценария (деньги, безопасность, SLA), частота изменений в этой части системы и фактическая история инцидентов — там, где инциденты повторяются, стоит добавлять тесты именно того уровня, который их бы поймал, а не слепо увеличивать долю одного типа тестов.
Пример кода
testing_example_323.txt
Пример распределения для платёжного сервиса с 5 внешними интеграциями:
- 70% unit-тестов бизнес-логики расчёта и валидации (мс на тест)
- 20% интеграционных тестов с тестовой БД и контрактных тестов на внешние API
- 10% e2e-сценариев: "оплата прошла и зачислена", "возврат средств"
Критерий ревью: каждый найденный в production баг должен добавлять тест
на том уровне, где он дешевле всего обнаруживается повторно.Что использовать на практике
- Практика. Для сервисов с множеством внешних интеграций стоит дополнительно инвестировать в контрактные тесты (consumer-driven contracts) на границах с партнёрами, чтобы не превращать каждую интеграцию в дорогой e2e-сценарий. Критичные денежные или безопасность-чувствительные пути оправдывают больше e2e-покрытия, несмотря на их стоимость.
Подводные камни
- Риск. Строить «перевёрнутую пирамиду» с преобладанием медленных e2e-тестов, из-за чего CI занимает часы, а разработчики начинают игнорировать падения. Или наоборот — полагаться почти исключительно на unit-тесты с моками, упуская целый класс ошибок интеграции, который проявляется только в production.