awesome-everything EN
↑ Обратно к восхождению

Инженерная практика

Контрактное тестирование: тест на припоминание

Суть Промпты на свободное припоминание по всему юниту контрактного тестирования. Сначала ответь своими словами, потом раскрой эталон и сравни.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбите
◷ 14 min

Припоминание бьёт перечитывание. На каждый промпт скажи или запиши полный ответ по памяти, прежде чем открыть эталон — именно усилие припоминания закрепляет механизм.

Цель

Восстанови позвоночник юнита — почему рушится e2e, как рождается pact, что доказывает provider verification, что добавляет can-i-deploy, как эволюционировать контракт и где контракты заканчиваются — не подглядывая в уроки.

Вспомните перед уходом
  1. 01
    Почему сквозное интеграционное тестирование рушится на масштабе и где именно в тестовой пирамиде дыра, через которую проскальзывает переименование поля?
  2. 02
    Пройди по тому, как рождается consumer-driven pact-файл, и почему это делает его доверительнее, чем рукописная OpenAPI-дока.
  3. 03
    Что реально делает provider verification, включая minimal-response-сравнение и роль provider states?
  4. 04
    Почему зелёной верификации недостаточно для деплоя и что вместо этого проверяет can-i-deploy? Почему версионировать по git SHA и записывать деплои в конце rollout?
  5. 05
    Как выкатить breaking-изменение провайдера, не ломая потребителей, и как pending/WIP-pact'ы обрабатывают зеркальный, consumer-led случай?
  6. 06
    Назови жёсткие границы контрактного тестирования и сениорское суждение про контракты против сквозных тестов.
Итог

Если ты смог восстановить каждый ответ по памяти, ты держишь позвоночник юнита: e2e рушится, потому что здоровье общего окружения — произведение аптаймов всех сервисов, поэтому совместимость спускают на слой каждого ребра; pact — запись прошедшего consumer-кода по типу, доверительная там, где дока гниёт; provider verification проигрывает каждое взаимодействие против реального сервиса и проверяет минимальную форму с state handler’ами, засевающими данные; can-i-deploy сверяет твою git-SHA-версию с реально развёрнутым; expand-then-contract плюс pending/WIP-pact’ы эволюционируют контракты без lockstep; а границы — форма, не семантика, только известные потребители, реальные накладные, расхождение фикстур и production — и есть причина, по которой всегда выживает тонкий слой настоящих e2e-smoke-тестов.

Продолжить восхождение ↑Контрактное тестирование: чтение кода и контрактов
хоткеи развернуть
поиск
K
пред. пьеса
k
след. пьеса
j
тиры
t
это меню
?
sources3
expand
  1. 01
  2. 02
  3. 03

Trademarks belong to their respective owners. Editorial reference only.