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

Тестирование HTTP API — это проверка работы API, через которое происходит взаимодействие с тестируемым сервисом. HTTP API (или веб-API) предоставляет интерфейс для обмена данными между различными приложениями, сервисами или компонентами системы через стандартные HTTP-запросы (например, GET, POST, PUT, DELETE).

Тестирование API особенно важно в современных микросервисных архитектурах, где множество независимых сервисов взаимодействуют друг с другом через API. Кроме того, API часто используются как интерфейсы для мобильных приложений и внешних клиентов.

Основные аспекты тестирования HTTP API

1. Проверка корректности HTTP запросов и ответов:
   • GET-запросы: Проверка, что запросы на получение данных возвращают правильные данные с правильным статус-кодом (например, 200 OK).
   • POST-запросы: Проверка, что запросы на создание новых данных успешно выполняются и создают ресурсы с корректным статус-кодом (например, 201 Created).
   • PUT/DELETE-запросы: Проверка, что запросы на обновление или удаление ресурсов работают правильно и возвращают соответствующие статус-коды (например, 200 OK или 204 No Content).
2. Проверка кода состояния HTTP:
   • Разные коды состояния (например, 200, 404, 500) должны правильно отображать результат запроса. Например, 404 должен возвращаться, когда запрашиваемый ресурс не найден, а 500 — при внутренней ошибке сервера.
3. Проверка структуры и содержимого ответа:
   • Проверка, что тело ответа имеет правильный формат (например, JSON, XML) и содержит все необходимые данные. Это может включать проверку наличия определенных полей, правильности типов данных, а также соответствия JSON-схемам.
4. Проверка обработки ошибок:
   • Проверка того, как API обрабатывает некорректные запросы или ошибки. Например, что происходит, если отправляется запрос с неправильными данными или отсутствуют обязательные параметры.

Настройка окружения

По умолчанию, Playwright запускает все тесты в браузере, поэтому сначала нужно изменить конфигурацию под запуск API-тестов. Мы уже делали это в уроке посвященному структуре тестов. Главное изменение там заключалось в разбиении типов тестов по директориям и указание в конфигурации как запускать эти тесты.

Структура директорий

• tests/: Главная директория для тестов.
  • e2e/: Тесты end-to-end (E2E).
  • unit/: Модульные тесты.
  • integration/: Интеграционные тесты, например тесты API.

Конфигурация

export default defineConfig({
  // Весь набор тестов будет запущен для каждого проекта
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
      testMatch: /e2e/,
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
      testMatch: /e2e/,
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
      testMatch: /e2e/,
    },
    {
      name: 'API Tests',
      testMatch: /integration/,
    },
    {
      name: 'Unit',
      testMatch: /unit/,
    }
})

Для API-тестов предназначена директория tests/integration.

Написание тестов

В качестве проекта для тестирования можно использовать любое публичное API. Мы, для примера, возьмем проект https://http.hexlet.app/http-api/openapi, который создан специально для подобных целей.

Напишем тест на адрес https://http.hexlet.app/js-playwright/tasks/1. Он возвращает информацию о задаче с id равным '1'. Сам тест:

// Произвольное имя файла
// tests/integration/jsonapi.spec.js
import test, { expect } from '@playwright/test'

test('tasks/:id', async ({ request }) => {
  const postId = '1'

  const response = await request.get(
    `https://http.hexlet.app/js-playwright/post/${postId}`,
  )

  // Проверяем что ответ 200
  expect(response.ok()).toBeTruthy()

  const data = await response.json()
  // Проверяем, что данные содержат параметр id со необходимым значением
  expect(data).toMatchObject(
    expect.objectContaining({
      id: postId,
    }),
  )
})

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

Для удобства выполнения запросов, Playwright передает в тест объект request, который по интерфейсу почти идентичен Fetch API. Для выполнения запросов с его помощью используются методы get(), post() и т.п. Для извлечения данных используется асинхронный метод json() если данные вернулись в этом формате.

Самое необычное в коде выше, то как выполняется проверка. Метод toMatchObject() проверяет частичное совпадение объекта. Такое бывает нужно, когда мы хотим проверить только часть полей если их много, они меняются после каждого запроса или не важны для теста. В целом, матчеры Playwright для тестирования данных идентичны матчерам тестового фреймворка Jest.

Для полноты картины, посмотрим на тест, который выполняет POST-запрос на создание новой сущности.

test('posts', async ({ request }) => {
  const data = {
    title: 'Пройти курс',
    description: 'Пройти курс по плейрайту за месяц',
    id: 10,
  }
  const response = await request.post('https://http.hexlet.app/js-playwright/tasks', {
    data,
  })

  expect(response.status()).toBe(201)

  const responseData = await response.json()
  expect(data).toMatchObject(expect.objectContaining(data))
})