Инженерная практика
Контрактное тестирование: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — почему рушится e2e, consumer-driven-запись, provider verification, гейт деплоя и жёсткие границы.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты реально принимаешь на платформе сервисов, деплоящихся независимо — не определение для заучивания, а компромисс под настоящей связанностью.
Цель
Убедись, что связываешь крах e2e на масштабе, consumer-driven-запись, provider verification, гейт can-i-deploy и границы — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Почему надёжность общего e2e-окружения деградирует по мере добавления сервисов и что из этого следует про решение?
Heads-up Возраст сервиса не причина. Даже при 98% зелёных у каждого склейка двенадцати роняет сценарий ниже 80%, потому что вероятности перемножаются — проблема в структуре, не в числе багов.
Heads-up Ресурсы — отдельная, чинимая проблема. Параллелизм не меняет форму N² — всё равно нужно одно общее окружение, зелёное целиком и сразу. В эту ловушку попадают прямо перед тем, как начать искать лучшее.
Heads-up Длина тестов не причина. Хрупкость — в рантайм-требовании, чтобы все сервисы были здоровы в один момент (перемножение аптаймов), а не в объёме написанного кода.
Викторина
Completed
Провайдер возвращает 40 полей; потребитель читает 4. Почему запись только этих 4 (по типу) — правильный охват для consumer-driven-контракта?
Heads-up Запись всех 40 делает контракт хрупким снимком, падающим на безобидных изменениях значений и на полях, которые никто не читает, порождая шум, из-за которого его глушат — та же эрозия доверия, что убила OpenAPI-доку команды.
Heads-up Только наличие даёт провайдеру сменить число на строку и проскочить гейт, пропуская реальную поломку. Потребитель парсит их как тип, поэтому именно тип и надо утверждать.
Heads-up Спека провайдера флагует каждое изменение одинаково, может разойтись с кодом и не знает, от каких полей кто зависит — шумная, склонная к гниению модель, которую consumer-driven-контракты и заменяют.
Викторина
Completed
Во время provider verification провайдер добавил три новых поля в ответ, не упомянутых в pact потребителя, но и переименовал одно поле, которое потребитель читает. Каков итог верификации?
Heads-up Provider verification — не точное совпадение. Она проверяет, что фактический ответ содержит хотя бы минимальную форму; лишние поля явно разрешены, что и даёт провайдеру эволюционировать поля, которые никто не читает.
Heads-up Число полей нерелевантно. Minimal-response-проверка ищет каждое утверждённое потребителем поле; переименованное потребляемое поле просто отсутствует под старым именем, поэтому это взаимодействие падает независимо от добавлений.
Heads-up Изменение формы никогда не пропускает верификацию — оно запускает сравнение. Верификация падает именно тогда, когда поле, которое читает потребитель, пропало или сменило тип, что и делает переименование.
Викторина
Completed
У взаимодействия `given` = 'a price with id 42 exists', но команда провайдера не написала обработчик этого состояния. Верификация падает. Как сениор должен это читать?
Heads-up Запрос и ожидаемый ответ валидны. Сбой — это отсутствующий на стороне провайдера обработчик состояния для строки `given`; правка pact лишь замаскировала бы реальное полезное покрытие.
Heads-up Provider states — предусловие, от которого зависит взаимодействие. Без обработчика данные не засеяны, поэтому повторённый запрос не даёт ожидаемый ответ — их никогда не игнорируют.
Heads-up Верификатор не пишет в хранилище провайдера из примеров pact — они описывают форму ожидаемого ответа, а не seed-данные. Провайдер обязан зарегистрировать обработчик, настраивающий данные.
Викторина
Completed
Новый pact потребителя зелено верифицирован против последней CI-сборки провайдера, пайплайн весь зелёный, поэтому он деплоится — и prod сразу падает. Какой вопрос был неверным и какой задаёт верный?
Heads-up Результаты не истекают по таймеру. Проблема в том, о какой версии провайдера результат — зелёное против latest ничего не говорит про более старую сборку, физически обслуживающую prod-трафик.
Heads-up Одна верификация правильной пары — заключительна. Дело не в числе прогонов, а в числе версий: верифицированная пара (новый потребитель, latest-провайдер) — не та пара, что создаётся при деплое (новый потребитель, развёрнутый провайдер).
Heads-up Версионирование по git SHA важно, потому что версия должна меняться, когда мог измениться контракт — голый semver может пометить два разных контракта. Но реальный пробел здесь — проверка против развёрнутого, а не latest, что делает только can-i-deploy.
Викторина
Completed
Все контракты проходят, но провайдер вернул структурно-идеальный `amount_cents: -500` для возврата, и checkout списал отрицательный баланс. Что это говорит о месте контрактного тестирования в стратегии?
Heads-up Ни один matcher не ловит это в общем случае — type matcher утверждает, что amount_cents целое, а -500 — валидное целое. Matcher'ы охраняют структуру, не бизнес-корректность; это категориальная граница, а не баг конфига.
Heads-up BDCT сравнивает pact со спекой — всё ещё чистая проверка формы и типов, без семантики значений. Он пропустил бы -500 так же легко. Чтобы поймать, нужен тест, утверждающий бизнес-правила, т.е. e2e или unit-логика.
Heads-up Контракты верно отправляют на пенсию бо́льшую часть флаки межсервисного e2e для известных внутренних пар. Урок — про пропорцию (много контрактов, немного e2e-smoke), а не про отказ от контрактов из-за их слепоты к семантике.
Итог
Сквозная линия юнита — один конвейер решений: e2e рушится, потому что здоровье общего окружения — произведение аптаймов всех сервисов, поэтому совместимость спускают на тест каждого ребра; потребитель записывает реальное использование по типу в pact; провайдер верифицирует, проигрывая каждое взаимодействие против реального сервиса и проверяя минимальную ожидаемую форму с provider states, засевающими данные; can-i-deploy превращает матрицу верификации в гейт деплоя, сверяя твою git-SHA-версию с реально развёрнутым; а жёсткая граница — контракты проверяют форму, не семантику — и есть причина, по которой выживает тонкий слой настоящих e2e-smoke-тестов. Каждый неверный ответ здесь — реальный неверный поворот реальной команды.