Тестирование API

Тестирование OpenAI-совместимого API перед rollout

OpenAI-совместимый API не следует принимать на веру по одному знакомому URL. Совместимость всегда имеет границы: другой каталог моделей, необязательные параметры, формат streaming, лимиты и обработка ошибок могут отличаться. Короткий контрактный набор до rollout превращает эти различия в наблюдаемые факты и помогает команде выпускать интеграцию без раскрытия ключей, дублей и ложных обещаний пользователям.

Опубликовано 18 августа 2026 · 12 минут чтения · Ключевой запрос: тестирование OpenAI-совместимого API

Сформулируйте контракт продукта

Тест начинается не с пакета SDK, а с ответа на вопрос: что именно должна делать функция? «Отправить prompt» слишком расплывчато. Опишите входную схему, допустимый размер, обязательные поля ответа, максимальное время, поведение при пустом результате и последствия ошибки. Например, для классификации вы можете требовать JSON с одним из трёх статусов; для чата — текст и контролируемое сообщение, если модель временно недоступна. Не тестируйте бренд модели вместо своей пользовательской задачи.

Разделите контракт на позитивные и негативные случаи. Позитивный случай проверяет валидный серверный запрос с утверждённой моделью. Негативные случаи покрывают пустой вход, слишком большой запрос, недопустимый параметр, неправильный ключ в изолированной тестовой переменной, неизвестную модель, тайм-аут и ограничение частоты. Цель не в том, чтобы «сломать» внешний сервис, а в том, чтобы ваше приложение стабильно классифицировало результаты и не показывало пользователю внутренние детали.

Проверьте текущий каталог первым

До chat completion запросите или откройте документированный список доступных моделей. Имя из старой статьи, демо или чужого репозитория не является гарантией. У ключа могут быть другие права, а каталог может измениться. Зафиксируйте в тестовом отчёте время проверки, environment и подтверждённый ID модели, но не сам ключ. Затем сравните возможности выбранной модели с контрактом: нужен ли streaming, tools, JSON-режим, длина контекста или определённый формат сообщения.

Проверка каталога также предотвращает плохую поддержку. Если тест не проходит из-за недоступной модели, не советуйте пользователю повторно вводить ключ и не меняйте endpoint ради обхода ограничений. Покажите понятное сообщение, сохраните безопасный request ID и выберите другой подтверждённый кандидат только после теста. Страница о /v1/models содержит минимальный путь проверки и правила для 401/403.

Минимальный контрактный тест

Следующий пример использует fetch в Node.js. Он запускается только на сервере или в CI со скрытыми secrets; значение переменной не печатается. Укажите модель, найденную в текущем каталоге. Поля choices проверяются осторожно, потому что отсутствие ожидаемого формата должно стать ясным сигналом теста, а не ошибкой доступа к неопределённому свойству.

import assert from 'node:assert/strict';

const response = await fetch('https://russiaapi.com/v1/chat/completions', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.RUSSIAAPI_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    model: process.env.RUSSIAAPI_MODEL,
    messages: [{ role: 'user', content: 'Ответьте одним словом: готово' }],
    max_tokens: 16
  })
});

assert.equal(response.ok, true, `status=${response.status}`);
const data = await response.json();
assert.equal(typeof data.choices?.[0]?.message?.content, 'string');

Это не универсальный smoke test для всех функций. Для вашего продукта добавьте проверку схемы, длины, запрещённых слов, вызова инструмента или формата streaming — только если это реальное требование. Не публикуйте ключ в примере, не передавайте его через query string и не встраивайте тест в клиентскую страницу. Изолируйте ключ тестовой среды, ограничьте бюджет и отзывайте его при подозрении на утечку.

Ошибки и лимиты тестируют безопасно

Тест 401 или 403 не должен использовать настоящий ключ с неправильными правами: применяйте отдельный пустой или заведомо тестовый secret и убедитесь, что журнал не записывает значение. Для неизвестной модели подставьте нейтральный несуществующий ID. Ожидаемый результат — ваше стабильное сообщение и классификация, а не конкретный текст upstream. Различайте ошибки входа, аутентификации, доступа, лимита и временного сбоя: одна кнопка «повторить» не годится для всех пяти случаев.

Проверять 429 потоком параллельных запросов небезопасно и не нужно. Локально протестируйте обработчик на mock-ответе с 429, проверьте ограничение попыток, backoff и очередь. Небольшие интеграционные проверки выполняйте только в допустимом тестовом режиме, опираясь на текущую документацию. При 429 приложение должно замедлиться или поставить работу в очередь, а не искать другой ключ или способ обойти лимит. Схема ограниченных повторов разобрана в статье о 429.

Данные, безопасность и наблюдаемость

Для первого набора используйте синтетические или обезличенные входы. Они должны отражать структуру реальных случаев: короткий текст, русский язык, неоднозначный запрос, длинный контекст и плохой формат. Не помещайте в fixture персональные данные, пароли, токены, платежные сведения или закрытые документы. Перед обработкой реальных данных команда должна отдельно оценить доступы, хранение, договорные требования и применимые правила.

Логируйте только то, что помогает принять решение: время, статус, задержку, классификацию, версию конфигурации, operation ID и метрику стоимости, если она доступна. Удаляйте из обычных журналов Authorization, API Key, cookie, prompts и полные ответы. Установите пороги выпуска: доля успешных контрактов, p95 задержки, отсутствие неожиданного формата и бюджет на тест. Такой набор даёт сравнимый результат при смене модели или SDK.

Выпускайте через контролируемый rollout

После CI не переключайте весь трафик одним коммитом. Поместите новую конфигурацию за feature flag, начните с небольшой доли безопасных сценариев и сравните её с текущим путём на одинаковых входах. Отслеживайте ошибки, тайм-ауты, отмены, стоимость завершённой задачи и сигналы от пользователей. Не сравнивайте случайные разные модели и разные лимиты: тогда причина изменения останется неизвестной.

Заранее определите rollback: кто его включает, какие метрики являются порогом и как вернуть предыдущую конфигурацию без потери задач. Если после сетевого обрыва статус неясен, не генерируйте новый результат автоматически; сначала примените operation ID и проверку состояния. Об этом подробнее написано в руководстве по тайм-аутам и отмене. Для миграции SDK используйте отдельный адаптер и сохраняйте известные границы совместимости рядом с кодом.

Чек-лист перед публикацией функции

• Контракт описывает вход, выход, deadline и ожидаемые ошибки, а не только «успешный prompt».
• Модель подтверждена текущим каталогом для нужного ключа и окружения.
• Тесты запускаются на сервере или в CI с отдельным secret, без печати ключа и данных.
• 429, 4xx, тайм-аут и неизвестный статус имеют отдельные безопасные ветки.
• Rollout ограничен feature flag и имеет измеримые пороги rollback.

FAQ

Читайте также

• OpenAI SDK в Node.js: подключение
• Миграция с OpenAI SDK
• Ошибки 401 и 403
• Документы RussiaAPI