Пробуем новый формат. Вместо пересказа чужих мыслей - свои собственные. Если формат зайдет (ставьте лайки), то буду периодически писать. Скорее всего темы будут про автотесты, инфраструктуру, процессы, архитектуру.

——

Устарела ли Пирамида тестирования?


Давайте немного расскажу про распределение видов тестов в проекте.

На данный момент есть 2 популярных модели - Пирамида Тестирования и Кубок Тестирования. Причем, пирамида нынче считается "устаревшей", а кубок - новой серебряной пулей.

Давайте сначала разберемся, а что такое Пирамида Тестирования.

Пирамида Тестирования - это метафора, которая представляет собой треугольник, разделенный горизонтальными линиями на 3 части. Эти 3 части - 3 слоя тестирования: юнит (нижний), интеграционный, е2е (верхний)

И при этом есть следующие правила
- Чем выше тест по пирамиде, тем он медленнее. Чем ниже - тем быстрее (юниты быстрые, е2е медленные)
- Чем выше тест по пирамиде, тем больше интеграций проверяется в тесте. Чем ниже - тем более изолированный тест получается (юниты мало чего проверяют, е2е проверяют все приложение разом)

В идеальной картине мира, нам нужно много тестов юнит слоя (быстрые, но изолированные), поменьше интеграционных (не такие быстрые, но уже проверяются интеграции) и совсем немного е2е (очень медленные, но зато проверяется интеграция всего со всем)

Если более абстрактно подходить к вопросу, то нас, кроме изолированности и скорости работы теста, вообще-то интересуют много вещей:
- Скорость написания\внесения изменений в тест
- Стабильность теста
- Сложность запуска
- и тд и тп

Кент Си Додс "похоронил" пирамиду тестирования и создал Кубок Тестирования. Кубок тестирования очень похож на пирамиду, только там предполагается большое наличие интеграционных тестов и малое количество юнитов и e2e. Предпосылка Кубка Тестирования - когда придумывали Пирамиду, не умели делать стабильные и быстрые интеграционные тесты. А теперь мы умеем делать такие тесты, а у нихц енность выше чем у юнитов, поэтому следует сместить фокус распределения на интеграционные тесты.

Теперь из каждого утюга можно услышать, что Пирамида устарела и все должны делать Кубок, что воспринимается многими как «не пишите юниты, пишите интеграционные тесты»

С Пирамидой действительно есть небольшая беда. В ней фундаментально правильные принципы, но вот картинка с тремя слоями все портит.

Пирамида она не про то, что нам нужны 3 слоя тестов и в какой пропорции они должны быть. Пирамида - это метафора про то, что у тестов есть разные атрибуты (скорость работы, стабильность, легкость поддержки, уровень доверия тесту и тд и тп). Все эти атрибуты - всегда трейдоф. Периодически мы учимся в узких кейсах делать одновременно и быстро и стабильно и с легкой поддержкой и с большим скоупом проверки, но в большинстве кейсов это все еще остается трейдофом.

Пирамида тестирования говорит о том, что нам, для достижения максимального эффекта от автоматического тестирования, необходимо комбинировать разные виды тестов в рамках одного проекта и даже в рамках проверки одного сценария. При этом, не обязательно ограничивать себя на конкретные 3 слоя. Вообще, на традиционной картинке с пирамидой - треугольник, не пирамида. Более близкой была бы метафора с настоящей пирамидой - у нас много сторон и на каждой стороне много уровней. Вот примерно так на самом деле и обстоят дела с видами автотестов на проекте - их много, они все разные и подходят для разных ситуаций. Задача разработчика - придумать как их скомбинировать для достижения оптимального эффекта. Пирамида - всего лишь способ визуализировать эту мысль.

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

https://d3jqtupnzefbtn.cloudfront.net/andersenlab/new-andersensite/bg-for-blocks/blueprint/win-the-testing-trophy/test-shapes-illustration.png