Разбор · 08.10.2026
Контрактное тестирование проверяет, совпали ли ожидания систем после правки ИИ-агента
Что запросить у команды перед выпуском: ожидания потребителя, проверку поставщика и совместимость версий. На документации Pact и поломках нашей машины агентов.
Текст подготовлен машиной агентов под редакцией Евгения Шилова · факты проверены 8 октября 2026
Контрактное тестирование проверяет, что запросы и ответы между системами соответствуют согласованным ожиданиям, даже если после правки ИИ-агента тесты отдельного сервиса остаются зелёными.
24 сентября 2026 на нашем сайте тесты оставались зелёными при несовместимом ответе; для CTO это причина проверить границу до выпуска.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Контракт защищает границу между системами.
Агент изменил API. Начните с того, кто читает ответ: поставщик отдаёт данные, потребитель использует их в своём коде. Ожидание живёт на этой границе.
Условный пример: агент переименовал customerId в customer_id. Сервис заказов проходит проверку по своей новой схеме, а кабинет клиента всё ещё читает старое имя.
У каждой проверки свой вопрос. Схема подтверждает форму ответа, контракт подтверждает согласованность обмена, тест бизнес-сценария подтверждает результат для пользователя.
Схема, контракт и бизнес-сценарий отвечают на разные вопросы.
Источник: Pact Docs, Introduction и Writing Consumer tests; проверено 8 октября 2026. Пример переименования поля условный.
2. Pact проверяет обе стороны одного ожидания.
Удачный JSON ещё не контракт клиента. В Pact ожидания фиксируются при выполнении теста потребителя, который обращается к тестовому поставщику.
Тест вызывает код клиента, который работает в продукте. Новый HTTP-запрос, написанный агентом только для теста, не подтверждает ожидания действующего клиента.
Поставщик исполняет запросы контракта на проверяемой версии. Pact сопоставляет ответы с ожиданиями; эту проверку включают в сборку до выпуска.
Ожидание проходит путь от клиента до разрешения выпуска.
Источник: Pact Docs, Introduction, Writing Consumer tests, Verifying Pacts и Can I Deploy; проверено 8 октября 2026.
3. Правку выпускают после проверки совместимости версий.
Зелёный прогон относится к проверенной паре версий. Совместимость с будущим клиентом не подтверждает совместимость с тем, который работает сейчас.
Pact Broker хранит контракты и результаты. Команда can-i-deploy проверяет совместимость для целевой среды; сведения о развёрнутых версиях обновляют после выпуска.
Брокер должен знать состояние среды. Устарели сведения о версиях, и проверяется не та пара. Отсутствие результата тоже не подтверждает совместимость.
Правка должна быть совместима с соседями в целевой среде.
Источник: Pact Docs, Can I Deploy и FAQ; проверено 8 октября 2026. Это условие совместимости, остальные проверки выпуска сохраняются.
4. Наши тесты пришлось дополнить проверками границы данных.
На vibecoding.ru инженер ведёт машину агентов. Наш опыт касается собственного сайта; клиентского кейса контрактного тестирования у нас нет.
Мы проверяем форму ответа и перенос полей, внедрения Pact не показываем. Метод описан по его документации; поломки сайта объясняют, зачем проверять границу.
Поломка добавляет проверку границы данных.
31.07
Поле, нужное для обложки, терялось на части путей создания новости. Перенос полей свели в общий маппинг, проверка ловит обход этого механизма.
24.09
Функция стала отдавать новое поле, которого не знал валидатор ответа; тесты оставались зелёными, часть страниц новостей отвечала ошибкой 500. Валидатор исправили, тест через exportReturns() сопоставляет поля ответа с объявленной формой.
Истории машины vibecoding.ru, 31 июля и 24 сентября 2026. Исходные записи и существующие проверки сверены 8 октября.
Новое поле не всегда ломает клиента: он может игнорировать его. Строгий валидатор отклоняет весь ответ; в нашем случае сработал именно валидатор.
Pact рекомендует проверять то, от чего зависит потребитель. Совпадение всего ответа с сохранённым образцом способно блокировать совместимые изменения.
Формат не доказывает правильность операции. Статус заказа может быть допустимым, а списание не произойти. Деньги и выдачу доступа проверяет бизнес-сценарий.
Проверка должна защищать нужное ожидание.
Источник: Pact Docs, Writing Consumer tests и When to use Pact; проверено 8 октября 2026. Условия проверки в таблице сформулированы автором.
5. Пилот принимают по несовместимости, которую тест поймал.
Начните с взаимодействия, которое агент меняет сейчас. Попросите команду назвать потребителя, поставщика и поля, от которых зависит действующий код.
В задачу для ИИ-агента запишите критерий: переименование нужного поля ломает проверку, исправленный обмен её проходит.
Проверьте саму проверку. В тестовой ветке удалите нужное поле и убедитесь в падении. Если агент заодно переписал ожидания ради зелёного результата, прежний клиент остался без защиты.
Пилот доказывает, что несовместимость делает проверку красной.
Источник: предложение автора на основе документации Pact, проверено 8 октября 2026. Это план пилота, не замер внедрения в клиентской компании.
6. Код и контракт принимают одной задачей.
Нашего замера внедрения Pact и экономии на чужой системе нет. Объём задачи зависит от доступа к обеим сторонам и возможности воспроизвести нужное состояние поставщика.
В старом коде без описания сначала найдите потребителей и зафиксируйте нынешнее поведение. Смена библиотеки тестов не заменит эту работу.
Ответственность за выпуск остаётся в компании. Владелец взаимодействия принимает новое ожидание; агент не объявляет его согласованным, поправив тест.
Код и подтверждение совместимости передаются вместе.
Источник: критерий приёмки, предложенный автором 8 октября 2026; сведения о версиях опираются на Pact Docs.
Открытая страница машины показывает работу над сайтом. Счётчик работы сам по себе не доказывает совместимость вашего API.
Можно начать с разбора текущей интеграции. Обсудите, кто читает ответ и какая проверка остановит несовместимую правку.
Тариф «Один проект» в подписке на разработку стоит 250 000 ₽/мес, один поток; проверено 8 октября 2026. Код и контракт обеих сторон поставьте одной задачей.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Метод Pact | Официальная документация: Introduction, Writing Consumer tests, Verifying Pacts, Can I Deploy, When to use Pact и FAQ. Проверены происхождение контракта, настоящий клиент, запуск поставщика и связь результатов с версиями; Pact в нашей машине не внедряли | 2026-10-08 |
| Поломки своего сайта | Перечитаны записи машины от 31 июля и 24 сентября 2026. Существующие проверки переноса полей и соответствия ответа валидатору сверены чтением кода, без запуска. В ленте последствия поломок и введённые после них проверки | 2026-10-08 |
| Поисковый спрос | Wordstat API, РФ: «контрактное тестирование», 233 запроса в месяц на 8 октября 2026. Частота не показывает число руководителей или покупателей | 2026-10-08 |
| Живые условия подписки | Страницы /open и /services прочитаны 8 октября 2026. Для статьи использована только цена «Один проект», 250 000 ₽ в месяц, и один поток работы. Цена относится к подписке; отдельной цены внедрения Pact на странице нет | 2026-10-08 |
| Граница нашего опыта | Своего клиентского внедрения Pact и замера экономии нет. План пилота и критерии приёмки предложены автором, а пример переименования поля условный | 2026-10-08 |
7. Частые вопросы
Контрактное тестирование заменяет интеграционные тесты?+
Оно проверяет согласованный обмен, отдельно проверяя потребителя и поставщика. Полный путь пользователя, побочные эффекты и работу инфраструктуры подтверждают другие тесты. Состав набора зависит от того, какую ошибку нужно поймать.
Обязательно ли использовать Pact?+
Нет. Контрактные проверки описывают метод. Pact реализует подход, где ожидания рождаются из тестов потребителя. В нашем примере отдельная проверка сопоставляет ответ с валидатором, без Pact.
Подойдёт ли метод для фронтенда и API?+
Да, потребителем может быть клиентский код веб-приложения. Проверяют код, который формирует запрос и обрабатывает ответ; внешний вид страницы остаётся задачей других тестов.
Можно ли менять контракт вместе с кодом?+
Можно, если новое ожидание согласовано и действующие потребители продолжат работать либо предусмотрен переход на новые версии. Переписать ожидание ради зелёной проверки недостаточно.
Есть ли польза, если поставщик чужой?+
Проверка своего клиента полезна, но его тестовый ответ не доказывает совместимость с реальным чужим сервисом. Для полноценного consumer-driven подхода нужно участие стороны поставщика. Без него требуется проверка фактического обмена, с условиями этого API.
Источники
- Pact Docs · Introduction; проверено 8 октября 2026 — документация
- Pact Docs · Writing Consumer tests; проверено 8 октября 2026 — документация
- Pact Docs · Verifying Pacts; проверено 8 октября 2026 — документация
- Pact Docs · Can I Deploy; проверено 8 октября 2026 — документация
- Pact Docs · When to use Pact; проверено 8 октября 2026 — документация
- Pact Docs · FAQ; проверено 8 октября 2026 — документация
- Открытая машина vibecoding.ru · наблюдение 8 октября 2026 — наш проект
- Подписка на разработку · условия «Один проект», проверены 8 октября 2026 — наш проект
Запомнить
1. При правке API назовите потребителя и его ожидания. Зелёный тест поставщика не подтверждает совместимость сам по себе.
2. Проверяйте настоящий клиент и настоящий код поставщика. Сохранённый JSON без этих проверок не защищает интеграцию.
3. Запрашивайте результат для версий, которые будут работать вместе. Привяжите несовместимость к остановке выпуска.
4. Принимайте код вместе с контрактом и доказательством, что намеренно сломанный обмен делает проверку красной.