Контрактное тестирование и борьба с flaky-тестами

Почему общее интеграционное окружение — не тот инструмент

К концу урока ты будешь знать, как поймать поломку API между сервисами до деплоя — без общего окружения — и почему «просто перезапусти» — это симптом сломанной стратегии, а не решение.

Когда два сервиса деплоятся одним релизным поездом, end-to-end тест, поднимающий оба, честен: он тестирует ровно то, что едет в прод. В тот момент, когда они начинают деплоиться независимо — нормальное состояние любого парка микросервисов — эта честность испаряется. Полноценное интеграционное окружение должно держать все сервисы разом, что делает его медленным в провижининге, дорогим в поддержании актуальности и магнитом для flaky: любой из N сервисов в процессе деплоя валит прогон по причинам, не связанным с твоим изменением. Хуже того — оно тестирует не тот вопрос. Тебе не важно, совместимы ли все сервисы между собой в каком-то снапшоте staging; тебе важно, не сломает ли версия, которую ты вот-вот задеплоишь, тех, кто от неё зависит, и не сломают ли её те, от кого зависит она.

Consumer-driven contract testing (тестирование на основе контрактов, продиктованных потребителем) отвечает ровно на этот вопрос, ни разу не запуская два сервиса в одном процессе. Идея: единственная часть API провайдера, которая имеет значение, — та, которой реально пользуются его consumer’ы. Так пусть каждый consumer запишет, как побочный продукт собственных unit-тестов, конкретные пары запрос/ответ, на которые он опирается, — эта запись и есть contract. Каждая пара запрос/ответ — это одна interaction: «когда я делаю GET /orders/42, я жду 200 с телом, где amount_cents — число». Тесты consumer’а гоняются против mock-провайдера, который проигрывает эти ответы, поэтому остаются быстрыми и изолированными. Затем provider забирает contract каждого consumer’а и в своём собственном pipeline проверяет, что может удовлетворить каждую interaction против настоящего хендлера. Переименование в checkout выше провалило бы provider-верификацию checkout’а в тот же миг, как прогнало бы contract orders’а — в собственном CI checkout’а, до мёржа, без единого задеплоенного где-либо orders.

Broker и can-i-deploy

Деталь, превращающая два pipeline’а в скоординированный gate, — это broker (Pact Broker или его хостед-форма PactFlow). Consumer публикует туда свой contract, помеченный своей версией и веткой/окружением, куда он направляется. Pipeline провайдера тянет нужные contract’ы из broker’а, верифицирует их и публикует результат верификации обратно. Так broker держит матрицу: для каждой версии consumer’а и версии провайдера — проверено ли, что эта пара совместима?

Эта матрица и питает can-i-deploy — собственно deploy-gate. Прежде чем выкатить версию X сервиса в окружение, ты спрашиваешь broker can-i-deploy --pacticipant orders --version X --to-environment production, и он отвечает «да» только если у каждого сервиса, с которым orders будет общаться в проде, есть записанная, прошедшая верификация против contract’а orders на версии X (и наоборот). Это запрос по уже собранным результатам, а не свежий прогон тестов, поэтому он мгновенный. В этом и разница с общим окружением: вместо того чтобы надеяться, что снапшот staging отражает прод, broker знает, какие именно версии совместимы, потому что каждая сторона доказала это в своём быстром pipeline.

Contract-тесты — не замена schema- или OpenAPI-проверок: они отвечают на более узкий, острый вопрос. OpenAPI-diff говорит, что спека изменилась ломающим образом; contract говорит, ломает ли это изменение реального consumer’а. Переименование поля, которое никто не читает, — ломающее изменение схемы, но не бьёт ни одного contract’а, поэтому деплоится свободно. Ужесточение поля, которое парсят три consumer’а, проходит схему (всё ещё валидный JSON), но валит их contract’ы. Используй schema-линтинг как дешёвый первый фильтр; используй contract’ы, чтобы гейтить по реальной связанности.

Flaky-тесты: убийца доверия

Как выглядит пайплайн, которым завладела flakiness? Ровно как в хуке: ночной прогон, который падает так часто, что письма от него никто не читает, и две команды деплоятся независимо без общего сигнала. Это состояние обратимо — но только если относиться к flaky как к проблеме качества с владельцем, а не как к фоновому шуму.

Flaky-тест проходит и падает на одном и том же коде без изменений между прогонами. Он опаснее стабильно красного теста, потому что red, который ничего не значит, приучает инженеров игнорировать red. Как только «да просто перезапусти» становится рефлексом, твой pipeline перестаёт быть gate’ом: реальный регресс прячется в шуме, люди мёржат по наитию, и вся ценность CI — что green значит безопасно мёржить — пропадает. Относиться к flaky как к самостоятельной проблеме качества, с бюджетом и владельцем, — это сеньорский ход; терпеть её — это как тест-сьют умирает.

Причины — короткий повторяющийся список, и название причины диктует фикс.

Воркфлоу вокруг них — три хода. Detect: перезапускай сьют по расписанию и трекай pass/fail по каждому тесту во времени, чтобы flaky показывалась дашбордом, а не ощущением. Quarantine: когда тест флакает, помечай его как quarantine, чтобы он всё ещё гонялся и репортил, но не гейтил мёрж, — и заводи тикет. Это защищает сигнал pipeline’а, пока ты чинишь тест, без худшей альтернативы — удалить его. Fix: дотащи его до детерминизма по таблице выше; quarantine — это карантин, а не кладбище, и список quarantine, который только растёт, сам по себе провал.

Вместе detect → quarantine → fix — единственный цикл, который реально сжимает flake-count; пропуск «fix» означает, что список карантина растёт, пока ты тихо не потерял покрытие половины кодовой базы.

Bounded retry — самый злоупотребляемый инструмент здесь. Авто-перезапуск упавшего теста, пока он не пройдёт, не чинит flaky — он её прячет, и спрячет реальный перемежающийся баг (настоящий race в проде) так же охотно. Единственное оправданное применение — маленький, ограниченный retry (например, 2 попытки) только на end-to-end тестах, где часть средовой flaky неустранима, и только когда каждый retry логируется и считается, чтобы flake-rate оставался видимым. Никогда не делай retry unit- или интеграционного теста: они должны быть детерминированными, и retry там — это признание, что ты пропустил фикс.