automationapitestingplaywrightqa

Автоматизация API-тестов: с чего начать и что покрывать в 2026

Команды любят автоматизировать через UI: наглядно, «как пользователь». А потом получают медленный, флейкучий прогон, который падает от смены вёрстки и гоняется полчаса. При этом бóльшую часть логики можно проверить на уровень ниже — по API: в разы быстрее, стабильнее (нет DOM и рендера) и баги ловятся раньше и дешевле. Если автоматизации у вас пока нет — начинать стоит не с UI, а с API. Разберём, что и как покрывать.

Почему API-тесты — фундамент

API-тест дёргает эндпоинт и проверяет ответ. Нет браузера, нет ожиданий анимаций, нет хрупких локаторов — поэтому он быстрый и стабильный. На пирамиде тестов это широкий средний слой: логика, валидация, права, граничные случаи проверяются здесь, а дорогие и медленные UI-тесты оставляют на несколько ключевых пользовательских сценариев.

Что проверять, кроме «пришёл 200»

Проверка «статус 200» — это ещё не тест. Хороший API-тест покрывает:

  • Статус-код под сценарий: 200/201 на успех, но и 400 (плохой ввод), 401 (без авторизации), 403 (нет прав), 404 (нет ресурса), 409 (конфликт), 422 (валидация), 429 (лимит), 5xx (не должно быть на валидном запросе).
  • Схему/контракт тела: ответ валиден по структуре и типам, а не «вроде похоже». Обязательные поля на месте, лишних нет, типы правильные.
  • Happy path и error paths: не только «всё хорошо», но и все ветки ошибок с внятным телом ошибки (код, message), а не голый 500.
  • Авторизацию: без токена, с чужим, с протухшим, с недостаточными правами → корректный отказ (см. broken access control).
  • Граничные и невалидные входные: пустые, слишком длинные, неверный тип, отсутствующие поля, инъекции — сервер отвечает предсказуемо, а не падает.
  • Идемпотентность: повтор одного и того же запроса (двойной POST, ретрай) не создаёт дубли.
  • Пагинация/фильтры/сортировка: границы страниц, пустой результат, некорректные параметры.

Данные: setup, teardown, изоляция

Главная причина флейков в API-тестах — грязные данные и зависимость от чужого состояния.

  • Setup через API или фикстуру: тест сам создаёт то, что ему нужно, а не надеется, что «пользователь 42 существует».
  • Teardown: убирает за собой (удаляет созданное), чтобы прогон был повторяемым.
  • Изоляция: тесты не мешают друг другу, можно гонять параллельно; уникальные идентификаторы (email/order с суффиксом), не хардкод.
  • Не зависеть от прод-данных и от порядка выполнения тестов.

Контракт: валидируй против схемы

Если у API есть OpenAPI/Swagger — используй его. Валидация ответа против JSON Schema / OpenAPI ловит дрейф: бэк тихо переименовал поле или поменял тип — тест краснеет сразу, а не «когда-нибудь в проде». Отдельный уровень — property-based тесты по OpenAPI (Schemathesis): инструмент сам генерит кучу входных данных и проверяет, что API не падает и не нарушает контракт.

Инструменты 2026

  • Playwright request — если уже на Playwright: API-тесты в том же раннере и репорте, что и UI, встроенные ассерты и фикстуры.
  • pytest + httpx/requests — гибкая классика для Python-команд.
  • REST Assured — стандарт для JVM (Java/Kotlin).
  • Postman + newman — коллекции в CI; хорошо для быстрого старта и ручной команды, врастающей в автоматизацию.
  • Hurl — plain-text DSL, идеален для простых проверок прямо в CI.
  • Schemathesis — property-based/фаззинг по OpenAPI, находит то, что не додумаешь руками.

Где в CI

API-тесты — быстрый слой, который не жалко гонять на каждый PR: секунды-минуты, стабильно, дают быстрый сигнал. UI-прогон (медленный) можно оставить на merge/ночь. Нужен тестовый бэкенд/окружение с предсказуемым состоянием — поднимать через Testcontainers/сиды или отдельный тест-стенд.

Чек-лист: хороший API-тест

  • Проверяет не только статус, но и схему/типы тела ответа.
  • Покрыты error-paths (400/401/403/404/409/422/5xx), а не только happy path.
  • Авторизация: без токена / чужой / протухший / без прав → корректный отказ.
  • Граничные и невалидные входные не роняют сервер.
  • Идемпотентность: повтор запроса не плодит дубли.
  • Пагинация/фильтры: границы, пустой результат, кривые параметры.
  • Тест сам создаёт данные (setup) и убирает за собой (teardown).
  • Тесты изолированы, можно гонять параллельно, не зависят от порядка.
  • Ответ валидируется против OpenAPI/JSON Schema (если есть).
  • Гоняется в CI на каждый PR, быстро и стабильно.

Коротко — что забрать с собой

  • Начинай автоматизацию с API, а не с UI: быстрее, стабильнее, дешевле.
  • «Статус 200» — не тест; проверяй схему, error-paths, авторизацию, границы, идемпотентность.
  • Флейки в API чаще от данных — делай setup/teardown и изоляцию.
  • Валидируй ответ против OpenAPI/JSON Schema, чтобы ловить дрейф контракта.
  • Держи API-тесты быстрым слоем в CI на каждый PR.

Почитать: Playwright — API testing · JSON Schema · Schemathesis (property-based по OpenAPI) · REST Assured · Hurl