Insomnia — API-клиент, в котором удобно исследовать запросы, читать описание API и собирать небольшие проверяемые сценарии. Для QA его ценность не в том, что запрос отправляется быстро, а в возможности сохранить контекст эксперимента: адрес, данные, способ авторизации и ожидаемый ответ. При работе с несколькими сервисами особенно важно отделять общие настройки от параметров конкретного стенда и не переносить состояние между независимыми проверками незаметно для себя.
Как устроена API Collection
В актуальной документации Kong API Collection объединяет запросы, папки, окружения и необязательную OpenAPI-спецификацию. Это полезная модель: описание контракта и реальные вызовы находятся рядом, однако совпадение расположения не гарантирует совпадение содержания. Сгенерированный запрос может содержать формально допустимый пример, который не соответствует реальным бизнес-правилам. После импорта QA всё равно проверяет обязательные поля, зависимости, роли и ожидаемые изменения данных.
Когда Insomnia особенно полезен
Инструмент подходит для исследования незнакомого API, сравнения ответов двух стендов, проверки авторизации и воспроизведения дефектов интеграции. Поддерживаются разные типы запросов, включая HTTP, GraphQL, gRPC и WebSocket, но сценарий выбирают по протоколу продукта. Наличие поддержки протокола не означает, что одна и та же проверка применима везде: HTTP-код не заменяет анализ GraphQL errors, а однократное сообщение не проверяет жизненный цикл WebSocket-соединения.
Окружения и приоритет значений
Окружения задаются JSON-объектами. Разделяй общий baseUrl, параметры стенда и временные данные сценария. В Insomnia есть уровни глобального окружения, коллекции и папки; более локальные значения могут перекрывать общие. Если запрос внезапно ушёл не туда, проверь итоговое значение переменной, а не только базовый JSON. Названия вроде staging-eu помогают ориентироваться, но проверка фактического домена перед изменяющей операцией остаётся необходимой.
Приватные подокружения и secret-переменные имеют специальные правила хранения и обращения. Выбранный режим синхронизации проекта также влияет на то, куда попадает информация. До совместного использования коллекции сделай пробный экспорт без реальных секретов и посмотри его содержимое. Не рассчитывай, что любой параметр, который выглядит локальным в интерфейсе, гарантированно отсутствует в Git или выгрузке.
Подготовка небольшого эксперимента
Рассмотрим каталог: GET /products?limit=2&cursor=... возвращает items и nextCursor. Контракт обещает стабильную сортировку по id внутри тестового набора. На изолированном стенде подготовлены пять товаров с известными идентификаторами; во время проверки набор не меняется. Такой контроль данных важен: новые товары между запросами могут изменить страницу и создать ложное впечатление, что сломана пагинация.
- →Сохрани отдельные запросы для первой страницы, следующей страницы, неверного cursor и недопустимого limit.
- →Для каждого запроса запиши роль пользователя, подготовку и проверяемое ожидание; понятное название лучше пометки «тест 1».
- →Сбрось старый cursor перед началом. Пустой и несуществующий cursor проверяй как разные входные ситуации, если контракт различает их.
Практика: проверка пагинации
- 1.Запроси первую страницу с limit=2. Ожидаются ровно два известных товара в обещанном порядке и курсор продолжения.
- 2.Подставь полученный nextCursor во второй запрос. Ожидаются следующие два товара без повторов из первой страницы.
- 3.Получи последнюю страницу. Ожидается оставшийся товар и предусмотренный контрактом признак окончания; не придумывай универсальное значение null для всех сервисов.
- 4.Передай заведомо повреждённый cursor. Ожидается понятная ошибка без утечки внутренней структуры запроса и без молчаливого возврата первой страницы, если это не оговорено.
- 5.Повтори последовательность после очистки временных значений. Ожидается тот же результат на том же наборе данных.
Скрипты до запроса и после ответа
Pre-request scripts используют для подготовки параметров, after-response scripts — для проверок ответа и передачи значений дальше. Для новой работы документация рекомендует эти скрипты: legacy unit tests скрыты по умолчанию начиная с указанной в документации ветки v13.3. Поэтому старое руководство с отдельной вкладкой тестов не стоит считать точным описанием установленного интерфейса. Сначала проверь версию клиента и актуальный scripting reference.
Проверку пагинации полезно разделить на независимые утверждения: items — массив, размер соответствует странице, идентификаторы уникальны, курсор пригоден для следующего шага. Не сохраняй новый cursor до проверки структуры ответа. В противном случае HTML-страница ошибки или пустой ответ могут сломать цепочку в другом месте, а диагностическое сообщение будет говорить о вторичном симптоме.
Состояние cookies и авторизации
Insomnia автоматически сохраняет cookies и может отправлять их в следующих запросах. Поэтому эксперимент «без токена» не всегда означает эксперимент без авторизации: сервер мог узнать пользователя по cookie. Перед негативной проверкой изучи все источники credentials, включая унаследованные заголовки и настройки папки. Сравни запрос чистой сессии с уже авторизованным. Для двух ролей лучше явно разделить контекст, чем постоянно заменять один и тот же токен вручную.
Как передать сценарий коллеге и CI
Вместе с коллекцией передай безопасные примеры конфигурации, версию контракта и описание подготовки данных. Для автоматического исполнения есть Inso CLI, но поддерживаемый формат, выбранную команду и поведение скриптов сверяют с версией runner. Сначала запусти один контролируемый сценарий в чистой среде и намеренно нарушь ожидание. CI должен показать падение именно проверки, а не лишь успешную отправку запросов или сохранение файла отчёта.
Ошибки, ограничения и практический вывод
Insomnia не проверит бизнес-правила вместо QA и не докажет корректность интерфейса браузера. API-клиент также не заменяет полноценный нагрузочный сценарий с заданной моделью пользователей. Типичные ошибки — импортировать спецификацию и считать покрытие готовым, забыть активные cookies, смешать стенды и принять старую переменную за свежий ответ. Качественный результат — компактная коллекция с явными данными, контролируемым состоянием и понятным объяснением, какой риск закрывает каждая проверка.