- Нужно делать акцент на интеграционные тесты
- Интеграционные тесты медленнее unit-тестов
Проверка fail path
Только интеграционные тесты позволяют это сделать, компонентные и E2E тесты не могут.
Testing Trophy > Test Pyramid
1. Реалистичность и эволюция
- Пирамида предполагает, что дешёвые юнит-тесты должны быть основанием, а интеграционных и E2E нужно мало.
- Проблема: реальность сложных систем (особенно микросервисов) - баги возникают не в арифметике функций, а в интеграциях, в glue-коде и неправильных API-контрактах. Юнит-тесты это не ловят.
- Trophy делает акцент на интеграционные тесты, потому что именно они приносят ценность в эволюционирующих системах.
2. Стоимость сопровождения
- Юнит-тесты легко пишутся, но их много и они ломаются при рефакторинге, даже если поведение не изменилось → они тормозят эволюцию.
- Интеграционные тесты дороже при написании, но дешевле в сопровождении: поведение меняется редко, контракты стабильнее, значит тесты живут дольше.
3. Фокус на пользовательском контракте
- Пирамида неявно подталкивает тестировать внутренности (методы, классы).
- Trophy фокусируется на контрактах: что сервис возвращает, как взаимодействуют компоненты, как выглядит конечный результат.
- Это лучше отражает реальность: бизнесу и пользователю всё равно, как устроен код, важно чтобы “VM поднялась и доступна по SSH”.
4. Управление рисками
- Юнит-тесты находят локальные ошибки, но пропускают системные.
- Интеграционные/компонентные тесты Trophy покрывают сразу больше сценариев с меньшими усилиями → меньше риск дыр в тестовом покрытии.
- Trophy оставляет место для E2E, но без оверхеда (их меньше, но они самые ценные).
5. Совместимость с современными практиками
- CI/CD, микросервисы, контрактное тестирование, Testcontainers - все они резко удешевили интеграционные тесты.
- Пирамида строилась в эпоху монолитов и тяжёлых моков. Trophy отражает сегодняшнюю экономику тестирования.
6. Баланс, а не утопия
- Trophy не говорит “не нужны юниты”. Они полезны для: – сложной бизнес-логики, – критичных алгоритмов, – локального TDD.
- Но юнит-тесты не должны занимать львиную долю, как диктует пирамида. Они вспомогательный инструмент.
📌 Главная мысль: Пирамида оптимизирует на “скорость прогона тестов”, Trophy оптимизирует на “ценность и надёжность обратной связи”. В реальной разработке (особенно в облаке/микросервисах) выигрывает второе.
Проверка порядка вызова в тестах
Проверка порядка должна применяться только если он является частью контракта системы. Если порядок вторичен - тест лучше формулировать инвариантами. Это снимает конфликт: ты признаёшь его кейс, но задаёшь критерий.