# API Testing

> Проверить реализованный API или границу сервиса по контракту, включая изменения состояния, авторизацию, совместимость и повторы. Применять для исполняемых проверок API; неустановленные условия контракта относятся к проектированию API, выбор покрытия между уровнями — к стратегии QA.

- Skill: `fbakiyev/api-testing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fbakiyev/api-testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fbakiyev/api-testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: fbakiyev (https://skillmd.com/u/fbakiyev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/fbakiyev/api-testing

---


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

## Выбрать границу и критерий правильности

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

## Случаи, различающие ошибки

- Проверяй смысл ответа и состояние, а не только коды статуса. Отклонённое изменение должно оставить защищаемое состояние неизменным, успешное — создать нужный эффект, а не только синтаксически правильный ответ.
- При изменении границ доступа проверяй полномочия на ресурс с разными субъектами и ресурсами. Действительные учётные данные одной учётной записи не разрешают доступ к данным другой. Тестовые данные и учётные данные должны оставаться в разрешённом тестовом окружении.
- Для идемпотентных изменений различай повтор одинаковых данных, одновременные дубликаты, тот же ключ с другими данными и повтор после потери подтверждения. Наблюдай и возвращаемый идентификатор, и число эффектов: два успешных ответа не доказывают однократность эффекта.
- При изменении контракта проверяй поведение старых клиентов для обязательных полей, значений по умолчанию, null, перечислений и ошибок. Одна проверка схемы не доказывает, что развёрнутый клиент допускает новое значение ответа.
- Для пагинации используй одинаковые значения сортировки и наборы данных на границах размера страниц; для асинхронных результатов проверяй документированное окно согласованности. Ожидания при одновременной вставке или удалении должны следовать выбранному контракту, а не придуманной гарантии снимка.

Используй только случаи, связанные с существенными рисками. Повторы тестового клиента должны быть видимы: автоматический повтор может скрыть неуспешную первую попытку или создать тот дублирующий эффект, который тест должен обнаружить.

## Реализация и результат

Изолируй тестовое состояние и удаляй только записи, созданные тестом. При необходимости подменяй внешние границы, сохраняя сериализацию запросов, смысл ошибок и проверяемую границу состояния. Заглушка сервиса не доказывает интеграцию с реальным сервисом.

При eventual consistency ожидай наблюдаемого условия с ограничением времени. По имеющимся данным обозначай таймаут как ошибку или ограничение окружения, а не как успех после паузы.

Верни исполняемые проверки, покрываемые ими случаи контракта, команды и результаты, а также важные пробелы интеграционной проверки. Если запрошено только проектирование тестов, верни случаи и критерии правильности, не заявляя об исполнении. Совместимость общих и публичных API должна оставаться явной.