← Все кейсы

Тестируем API с помощью TestMW

Почти в каждом сценарии для личного кабинета первые пять шагов одинаковые и скучные: открыть страницу входа, дождаться формы, ввести логин, ввести пароль, нажать «Войти», подождать редиректа. Это работает — но это самое хрупкое место теста: поехала вёрстка формы, поменяли id поля, добавили капчу или «запомнить меня» — и весь сценарий падает ещё на пороге, не дойдя до того, что вы на самом деле хотели проверить.

А ещё бывает обратная задача: проверить не кнопку, а бэкенд. Отдаёт ли API список заказов, правильный ли там статус, не сломался ли фильтр. Кликами по интерфейсу это проверять долго и косвенно.

Идея: логин по API + переиспользование токена

Шаг «API-запрос» выполняет HTTP-запрос прямо внутри сценария. Важное свойство: запрос идёт через тот же браузер, что и остальные шаги, поэтому cookies и сессия общие. А значения из ответа (токен, id) шаг умеет складывать в слот — и дальше вы переиспользуете их в любых шагах через rmb:slot_1.

Сценарий целиком

Шаг 1. «API-запрос» — авторизация. Логинимся одним запросом и сохраняем токен из ответа в слот:

{
  "method": "POST",
  "url": "https://api.site.com/auth/login",
  "headers": { "Content-Type": "application/json" },
  "body": { "login": "qa@site.com", "password": "secret" },
  "save": { "slot_1": "body.access_token" },
  "assert": [ { "path": "status", "op": "=", "value": "200" } ]
}

Здесь save достаёт access_token из тела ответа и кладёт его в Слот 1. assert сразу проверяет, что логин прошёл (код 200) — если сервер вернул 401, тест падает уже на этом шаге.

Шаг 2. «API-запрос» — выгрузка списка объектов. Тот же токен подставляем в заголовок Authorization через rmb:slot_1 — воркер заменит его на сохранённое значение перед отправкой:

{
  "method": "GET",
  "url": "https://api.site.com/orders?limit=50&status=paid",
  "headers": { "Authorization": "Bearer rmb:slot_1" },
  "save": { "slot_2": "body.items[0].id" },
  "assert": [
    { "path": "status", "op": "=", "value": "200" },
    { "path": "body.total", "op": ">", "value": "0" }
  ]
}

Проверяем, что список отдался (код 200) и что в нём есть хотя бы один объект (body.total > 0). Заодно сохраняем id первого объекта в Слот 2 — он пригодится дальше.

Шаг 3. «Перейти на страницу» — открываем объект в интерфейсе. Токен уже в сессии браузера (запрос шёл через него), а id объекта лежит в слоте — подставляем его прямо в URL:

https://site.com/orders/rmb:slot_2

Шаг 4. «Я вижу» — Заказ оплачен. Убеждаемся, что тот самый объект, который вернул API, реально открывается и отображается в интерфейсе.

Что получилось

  • Быстро и устойчиво: вход — один запрос вместо пяти хрупких шагов по форме. Капча и редизайн страницы логина сценарий больше не ломают.
  • Проверили бэкенд и фронт разом: API отдаёт список (шаг 2), а интерфейс показывает конкретный объект из этого списка (шаги 3–4).
  • Токен переиспользуется одним и тем же механизмом слотов, что и «Запомнить текст»: сохранили в save → пишете rmb:slot_1 где угодно (в заголовке следующего API-запроса, в шаге «Установить заголовки», в URL перехода).

Полезные детали

  • Отдать токен браузеру для навигации. Если защищённые страницы требуют заголовок Authorization при обычном переходе — поставьте между шагами «Установить заголовки» со значением Authorization: Bearer rmb:slot_1.
  • Пути в ответе. В save и assert доступны status, text, body.поле, вложенность и массивы (body.items[0].id), а также headers.Имя.
  • Проверки. Операторы = != > < >= <= IN "NOT IN" LIKE. Например, { "path": "body.status", "op": "IN", "value": "paid,shipped" }.
  • Безопасность. Разрешены только http/https, запросы на внутренние/приватные адреса блокируются. AI-токены и деньги шаг не тратит.

Из «пяти скучных шагов ради логина» получился один надёжный — а сверху бесплатно приехала проверка бэкенда.