QA-Логия

Schema drift в продакшене: контрактные пробы для внешних API до поломки интеграций Внешние API часто ломают интеграции не outage, а тихим изменением схемы при 200 OK. В CI/CD, release validation и on-call это поздно видно как падение парсера, потому что QA и dev проверяют статус-код вместо контракта. Что дрейфует * amount был number, стал string * nullable поле стало обязательным * enum получил новое значение * массив превратился в объект * deprecated поле исчезло без смены версии Healthcheck это не поймает: latency зеленая, SLA жив, а потребитель уже не умеет обработать ответ. Контрактная проба Это маленький production-oriented вызов внешнего API, который регулярно проверяет минимальный контракт потребителя, а не весь ответ провайдера.

schema = {
 "required": ["id","status","amount"],
 "properties": {
  "id": {"type":"string"},
  "status": {"enum":["created","paid","cancelled"]},
  "amount": {"type":"number"}
 },
 "additionalProperties": True
}

r = get("/payments/test-id", timeout=3)
assert r.status_code == 200
validate(r.json(), schema)

Важный trade-off - tolerant reader: новые лишние поля не должны ломать тест, но breaking changes должны давать алерт. Как запускать * каждые 1-5 минут для критичных API * из того же региона, что и прод * с test credentials и стабильными сущностями * с метрикой contract_probe_success * с diff ответа в алерте Практический совет: держите контракт рядом с кодом потребителя и проверяйте инварианты вроде amount >= 0 и paid не без paid_at. Типичная ошибка Не делайте snapshot всего ответа и не смешивайте пробу с длинным E2E: получите шумный feedback loop и дорогую поддержку. Вывод: Контрактные пробы не заменяют регрессию, но ловят schema drift до пользовательского инцидента.