API-тестирование в Playwright без браузера: request context

Playwright умеет тестировать не только UI через браузер, но и напрямую HTTP API — без открытия страницы вообще. Для этого используется request context: отдельный API-клиент, который отправляет реальные HTTP-запросы (GET, POST, PUT, DELETE) и проверяет ответ по статус-коду, заголовкам и телу — без запуска Chromium, Firefox или WebKit. Это быстрее браузерных тестов на порядок, потому что не тратится время на рендеринг страницы, загрузку скриптов и стилей.

import { test, expect } from '@playwright/test';

test('получить список пользователей', async ({ request }) => {
const response = await request.get('/api/users');
expect(response.status()).toBe(200);

const users = await response.json();
expect(users.length).toBeGreaterThan(0);
});

Фикстура request доступна в тесте так же, как page — Playwright сам создаёт для неё контекст. request.get(url) отправляет реальный GET-запрос и возвращает объект ответа, у которого можно проверить статус-код (response.status()), заголовки (response.headers()) и распарсить тело как JSON (await response.json()). Никакого браузера при этом не запускается — тест работает быстрее, чем эквивалентная проверка через UI.

test('создать нового пользователя', async ({ request }) => {
const response = await request.post('/api/users', {
data: {
name: 'Игорь',
email: 'igor@example.com',
},
});

expect(response.status()).toBe(201);
const created = await response.json();
expect(created.id).toBeDefined();
expect(created.name).toBe('Игорь');
});

request.post(url, { data }) отправляет POST-запрос с телом, сериализуя объект data в JSON автоматически (заголовок Content-Type: application/json проставляется сам). Статус 201 Created — стандартный код для успешного создания ресурса, а не 200 OK, что часто путают в тестах. Проверка created.id подтверждает, что сервер действительно создал сущность и вернул её данные, включая сгенерированный идентификатор.

test.use({
extraHTTPHeaders: {
Authorization: `Bearer ${process.env.API_TOKEN}`,
},
});

test('получить приватные данные пользователя', async ({ request }) => {
const response = await request.get('/api/profile');
expect(response.status()).toBe(200);
});

test.use({ extraHTTPHeaders }) настраивает заголовки, которые будут автоматически добавляться ко всем запросам в тестах этого файла или блока — удобно для токена авторизации, который иначе пришлось бы прописывать в каждом отдельном запросе. Токен здесь берётся из переменной окружения, а не хардкодится в коде теста, что важно и для безопасности, и чтобы одни и те же тесты работали в разных окружениях (локально, staging, CI) с разными реальными токенами.

test('заказ появляется в интерфейсе после создания через API', async ({ request, page }) => {
const response = await request.post('/api/orders', {
data: { product: 'Курс Middle QA', amount: 190000 },
});
const order = await response.json();

await page.goto(`/orders/${order.id}`);
await expect(page.getByText('Курс Middle QA')).toBeVisible();
});

Одна из практических причин использовать request context — быстрая подготовка тестовых данных через API перед проверкой UI, вместо того чтобы каждый раз кликать через интерфейс, чтобы создать нужное состояние (например, оформить заказ вручную только для того, чтобы потом проверить, что он отображается в личном кабинете). Тест выше создаёт заказ напрямую через API за миллисекунды, а затем проверяет только то, что действительно нужно тестировать — отображение в UI, а не сам процесс создания.
Важный нюанс: фикстура request — самостоятельный API-контекст, независимый от браузера, и куки, выставленные через request, не видны page при переходе по страницам. Для сценариев, где нужна общая сессия между API-запросами и браузером (например, авторизация через API-запрос, после которой page должен открыть уже залогиненную страницу), используют не отдельную фикстуру request, а page.request — она делит контекст (включая куки) с самим page.

Чем request context отличается от обычных инструментов вроде Postman? Request context встроен в тот же фреймворк и тот же тестовый прогон, что и UI-тесты — можно комбинировать проверку API и браузера в одном тесте, использовать общие фикстуры и конфигурацию, и запускать всё вместе в CI одной командой, без переключения между инструментами.
Нужен ли браузер для API-тестов через request context? Нет, request context работает независимо от браузера — можно писать и запускать чисто API-тесты в проекте на Playwright вообще без единого вызова page, что делает их быстрее полноценных браузерных тестов.
Как передать query-параметры в GET-запросе? Через объект params в опциях запроса: request.get('/api/users', { params: { role: 'admin' } }) — Playwright сам соберёт строку запроса из объекта.
Можно ли использовать API-тесты для подготовки данных перед UI-тестом? Да, это одно из главных практических применений — создание тестовых данных (пользователей, заказов, записей) напрямую через API значительно быстрее и стабильнее, чем воссоздание того же состояния через клики в интерфейсе, особенно если состояние сложное и требует много шагов.

Подготовка тестовых данных через API вместо кликов в интерфейсе — навык, который стоит попробовать на реальном проекте. Бесплатный тренажёр Playwright Arena — для основ. Для полноценного проекта автотестов с ментором — курс «Автотестирование JS/TS + Playwright» в Quality Academy.

-------

Сайт Quality Academy:
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena