Пирамида тестирования умерла. Просто мы 10 лет делали вид, что не замечаем 📈

Наткнулся на статью с неожиданно простой мыслью. Классическая пирамида Фаулера от 2012 года отвечает на один вопрос: сколько тестов какого типа держать, с акцентом на стоимость и скорость. Но когда на собесе просят "расскажи про пирамиду тестирования", все начинают перечислять unit, integration, e2e, и разговор незаметно съезжает с "сколько и почему" на "какие виды тестов бывают". Это уже другой вопрос, и пирамида на него плохо отвечает.

Автор предлагает смотреть на quality checks не как на слои одной фигуры, а через три координаты сразу: этап жизненного цикла, окружение, и что именно проверяется.

Шесть этапов по DevOps Infinity Loop: Write → Commit → Build → Verify → Release → Operate. И у каждого свои допустимые окружения: Local, CI, Staging, Pre-prod, Prod. Write происходит только локально. Operate только в проде. А Verify, то есть собственно тестирование, может жить и в CI, и на стейдже одновременно.

Что цепляет: проверки идут даже на этапе написания кода, когда ещё ничего не закоммичено. Линтер, статический анализ, подсказки IDE это тоже quality check, просто не "тест" в привычном смысле. Автор специально развёл термины: не каждая проверка является тестированием, и это снимает вечный спор "это юнит-тест или уже интеграционный".

Финальная мысль простая, но по делу: чем раньше поймали ошибку, тем меньше шагов до исправления. А отсутствие проверок на каком-то этапе и размытые зоны ответственности это не абстрактный риск, а конкретная дыра, которая рано или поздно вылазит в проде.

Полезно не как замена пирамиде, а как дополнение. Особенно когда защищаешь процесс перед командой и нужно показать не просто "у нас есть unit-тесты", а где именно в цепочке что проверяется и кто за это отвечает.

Статья