Тестирование API является важной частью процесса разработки, особенно при интеграции сторонних сервисов и работы с данными. В WebdriverIO предусмотрены инструменты для тестирования API, что позволяет легко интегрировать проверки в автоматизированные тесты. В этой части будет рассмотрен процесс проверки ответов от API с использованием WebdriverIO.
webdriverio для тестирования APIWebdriverIO предоставляет несколько способов взаимодействия с API, но
наиболее часто используется встроенная возможность для работы с
HTTP-запросами, используя популярную библиотеку axios. Это
позволяет легко интегрировать API-тесты в автоматизированный процесс
тестирования веб-приложений.
Для начала необходимо установить WebdriverIO и нужные библиотеки. Основной установочный пакет WebdriverIO можно установить через npm:
npm install webdriverio
npm install axios
После этого можно настроить API-запросы в тестах с помощью
axios или использовать встроенную поддержку HTTP-запросов в
WebdriverIO.
axiosЧтобы проверить ответ от API, нужно отправить HTTP-запрос к нужному
ресурсу. Для этого можно использовать axios, который
является популярным инструментом для выполнения HTTP-запросов.
Пример запроса с использованием axios:
const axios = require('axios');
describe('Проверка ответа от API', () => {
it('Проверка успешного ответа API', async () => {
const response = await axios.get('https://jsonplaceholder.typicode.com/posts/1');
// Проверка успешности ответа
expect(response.status).toBe(200);
// Проверка содержимого ответа
expect(response.data.id).toBe(1);
expect(response.data.title).toBeDefined();
});
});
В данном примере отправляется GET-запрос к API, проверяется статусный код ответа и проверяется наличие определенных данных в теле ответа.
WebDriverIO для работы с APIWebdriverIO имеет встроенную возможность для работы с API-запросами
через использование команд типа request. Для этого
необходимо подключить плагин wdio-request в конфигурации
теста.
Пример настройки конфигурации для работы с API:
exports.config = {
services: [
['request']
]
};
После того как сервис настроен, можно выполнять HTTP-запросы прямо в тестах:
describe('Тестирование API с WebDriverIO', () => {
it('Проверка успешного ответа API', async () => {
const response = await browser.call(async () => {
return await browser.request({
method: 'GET',
url: 'https://jsonplaceholder.typicode.com/posts/1'
});
});
// Проверка ответа от API
expect(response.status).toBe(200);
expect(response.body.id).toBe(1);
expect(response.body.title).toBeDefined();
});
});
В данном примере используется browser.call, чтобы
асинхронно получить ответ от API и выполнить необходимые проверки.
Преимущество такого подхода в том, что он интегрируется непосредственно
в тесты WebDriverIO и позволяет использовать все возможности тестового
фреймворка.
С помощью WebdriverIO можно тестировать как запросы типа GET, так и POST, PUT, DELETE и другие. Пример использования POST-запроса для отправки данных:
describe('Тестирование POST-запроса', () => {
it('Отправка данных через POST-запрос', async () => {
const response = await browser.call(async () => {
return await browser.request({
method: 'POST',
url: 'https://jsonplaceholder.typicode.com/posts',
data: {
title: 'foo',
body: 'bar',
userId: 1
}
});
});
// Проверка успешности запроса
expect(response.status).toBe(201);
expect(response.body.title).toBe('foo');
});
});
В этом примере отправляется POST-запрос с JSON-данными. Статусный код 201 подтверждает, что ресурс был успешно создан. Также проверяется, что в ответе содержатся данные, которые были отправлены на сервер.
Не все ответы от API являются успешными, и важно проверять различные сценарии с ошибками, например, когда сервер не может обработать запрос или когда отсутствуют необходимые данные. Рассмотрим пример обработки ошибки 404 (ресурс не найден):
describe('Проверка ошибок API', () => {
it('Проверка ответа 404', async () => {
const response = await browser.call(async () => {
return await browser.request({
method: 'GET',
url: 'https://jsonplaceholder.typicode.com/posts/9999' // Несуществующий ресурс
});
});
// Проверка, что статус ошибки 404
expect(response.status).toBe(404);
});
});
В данном случае проверяется, что при запросе к несуществующему ресурсу сервер возвращает статусный код 404.
Многие API требуют авторизации для доступа к ресурсам. WebdriverIO позволяет использовать различные методы авторизации, такие как Basic Auth или Bearer Token.
Пример с авторизацией через заголовки:
describe('Проверка авторизации в API', () => {
it('Проверка ответа с авторизацией', async () => {
const response = await browser.call(async () => {
return await browser.request({
method: 'GET',
url: 'https://jsonplaceholder.typicode.com/posts',
headers: {
'Authorization': 'Bearer <your_token>'
}
});
});
expect(response.status).toBe(200);
expect(response.body).toBeInstanceOf(Array);
});
});
Здесь в запрос добавлен заголовок Authorization, который
содержит токен для доступа к защищенным ресурсам. Это может быть полезно
для тестирования API, которые требуют аутентификацию.
Когда необходимо протестировать приложение, но нет возможности
обращаться к реальному API, можно использовать мокирование (mocking)
ответов. В WebdriverIO это можно сделать с помощью библиотеки
nock.
Пример мокирования GET-запроса с использованием
nock:
const nock = require('nock');
describe('Мокирование API', () => {
it('Проверка мока GET-запроса', async () => {
nock('https://jsonplaceholder.typicode.com')
.get('/posts/1')
.reply(200, {
id: 1,
title: 'foo',
body: 'bar'
});
const response = await axios.get('https://jsonplaceholder.typicode.com/posts/1');
expect(response.status).toBe(200);
expect(response.data.title).toBe('foo');
});
});
Здесь с помощью nock перехватывается запрос к API и
возвращается заранее подготовленный ответ. Это позволяет протестировать
логику работы с API без реального обращения к серверу.
Проверка API-ответов является важной частью тестирования современных веб-приложений. В WebdriverIO можно удобно интегрировать тестирование API-запросов в автоматические тесты, используя стандартные инструменты или дополнительные библиотеки. Возможности WebdriverIO позволяют выполнять тесты как для успешных запросов, так и для ошибок, обеспечивая полное покрытие сценариев.