Как обеспечить надёжность API и AI-интеграций: тестирование, инспекция и инъекция сбоев с помощью MockServer

Я — Denis Shokhirev, Enterprise AI architect, Freiburg. В DennisCraft AI Studio я внедряю AI-агентов для DACH-клиентов в B2B сегменте: логистика, финтех, автоматизация. За последние 6 месяцев я вывел в прод 14 AI-агентов на стеке Claude, Supabase, n8n, Doppler, self-hosted Postgres. В одной из интеграций, когда внешнее API внезапно вернуло неконсистентный ответ, мой пайплайн «упал» в prime-time. Не хватило одного слоя: изолированного тестирования на сбои и аномалии.

Почему классические тесты не спасают интеграции

В большинстве проектов API и AI-интеграции тестируются на happy path — корректные данные, стабильный сервис. Но реальный прод диктует другое: нестабильные ответы, нестандартные ошибки, таймауты, невалидные схемы. На практике даже зрелые команды часто не имитируют эти сценарии. При этом, согласно опросу State of API 2023 от Postman (ссылка), 51% инцидентов с API в проде связаны с ошибками обработки нестандартных ответов.

Я наблюдал это лично: 3 из 14 последних AI-агентов ловили баги только на реальных сбоях, которые не покрывались простыми unit-тестами.

MockServer: зачем и когда применять

MockServer — open source инструмент (Java, Docker), позволяющий моделировать поведение внешних API: возвращать кастомные ответы, эмулировать ошибки, задержки, неконсистентные данные. В отличие от простых моков (unittest.mock, sinon), MockServer работает как полноценный HTTP(S)-сервер, поддерживает сложные сценарии и может использоваться как в CI/CD, так и в ручном тестировании.

Типовые сценарии применения MockServer

1. Инъекция сбоев и аномалий

Сценарии: HTTP 500/503, таймауты, повреждённый JSON, неожиданные поля. Так ловятся баги, которые не проявляются на чистых данных.

{
  "httpRequest": {
    "method": "POST",
    "path": "/payment"
  },
  "httpResponse": {
    "statusCode": 500,
    "body": "{\"error\": \"Internal server error\"}"
  }
}

2. Инспекция и логирование запросов

MockServer логирует все входящие запросы: можно видеть, что реально уходит во внешние сервисы (особенно важно для AI-пайплайнов, где payload часто генерируется динамически). Это быстро выявляет лишние поля, ошибки сериализации и неявные зависимости.

import requests

def send_payload(data):
    response = requests.post('http://localhost:1080/payment', json=data)
    return response.json()

3. Тестирование на стабильность пайплайна

Я использую MockServer для нагрузочного тестирования: например, 20% ответов возвращают ошибку, остальные — валидный JSON. Так можно проверить, не «сыпется» ли retry-логика, правильно ли агрегируются ошибки.

{
  "httpRequest": {
    "method": "POST",
    "path": "/payment"
  },
  "times": {
    "remainingTimes": 2
  },
  "httpResponse": {
    "statusCode": 500,
    "body": "{\"error\": \"DB failure\"}"
  }
}

Встраивание MockServer в AI-стек (Claude, Supabase, n8n)

Автоматизация через n8n и Supabase

MockServer отлично интегрируется с n8n: можно запускать мок-сценарии перед пайплайном, замыкать внешние вызовы на sandbox, логировать все обращения в Supabase. Для AI-агентов на Claude я часто соединяю MockServer с тестовой базой Supabase — все запросы к внешним API проходят через него, что позволяет имитировать сбои и валидировать payload.

// n8n HTTP Request node к MockServer вместо реального API
{
  "method": "POST",
  "url": "http://mockserver:1080/payment",
  "body": {
    "user_id": "123",
    "amount": 100
  }
}

CI/CD и изоляция тестов

MockServer поднимается в docker-compose вместе с тестовой средой. Такой подход даёт полную изоляцию: никакой зависимости от реального API, сценарии сбоев воспроизводимы. Это критично для regulated-рынков, где API-сервис может менять поведение из-за правовых изменений или лимитов.

services:
  mockserver:
    image: mockserver/mockserver
    ports:
      - 1080:1080

Расширение: статический анализ и интеграция c semgrep/bandit/gitleaks

MockServer не заменяет статический анализ (semgrep, bandit, gitleaks), но позволяет «проигрывать» сценарии, которые статические инструменты не ловят: например, race condition при ошибках API или некорректное логирование приватных данных в AI-пайплайне.

FAQ

Чем MockServer отличается от WireMock?

WireMock — аналогичный инструмент, но больше заточен под Java-экосистему. MockServer проще интегрировать в polyglot-стек (Python, Node.js, Go), легко запускается в Docker и CI/CD.

Можно ли использовать MockServer для тестирования AI-интеграций с LLM?

Да, но важно моделировать не только ошибки API, но и аномальные/невалидные JSON-ответы, которые LLM может возвращать при генерации. Это позволяет вылавливать edge-case-бага на ранних этапах.

Сколько времени занимает внедрение MockServer в стек?

В среднем, на базовую интеграцию уходит 2-3 дня: настройка docker-compose, написание сценариев, интеграция с пайплайном. Дальше сценарии расширяются по мере роста покрытия.

Можно ли использовать MockServer в production?

В проде MockServer не используется как proxy, только для тестов и staging. Важно не смешивать тестовые сценарии и реальные вызовы.

Как логировать и анализировать запросы?

MockServer ведёт подробный лог каждого запроса. Можно выгружать историю обращений, интегрировать с Supabase для хранения аудит-логов.

Ваша интеграция AI и API уже ловила баги только на реальных сбоях, или вы полагаетесь на happy path? Каков ваш реальный процент покрытых edge-case сценариев? Я делаю бесплатный 30-мин аудит стека для DACH-команд, внедряющих AI в регулируемых рынках. Пишите в LinkedIn или на @ger_dennis_ai.