Тестирование API в Playwright/Java. PATCH-запросы

• Особенности PATCH-запроса
• Установка и настройка
• Сценарий: обновление заказа
  • Реализация теста
  • Генерация токена аутентификации 
  • Генерация тестовых данных обновления заказа
  • Обновление заказа с помощью PATCH-запроса 
  • Выполнение теста

Чем отличается PATCH-запрос

PATCH-запрос предназначен для частичного обновления ресурса. Это по сути такой же запрос как и PUT, но разница в том, что PUT требует отправки всего тела запроса, в то время как с помощью PATCH мы можем указать только отдельные поля в запросе, которые нужно обновить.

Еще одно отличие между PUT и PATCH заключается в том, что PUT-запрос всегда идемпотентен, то есть повторное выполнение одного и того же запроса не изменяет состояние ресурса, в то время как PATCH запрос не всегда бывает идемпотентным. 

Ниже приведен пример обновления заказа с помощью PATCH запроса с использованием API restful-ecommerce.

1. PATCH/partialUpdateOrder/{id} — Частичное обновление заказа с использованием id заказа.

Этому API нужен id, то есть order_id, в качестве параметра пути для проверки существующего заказа и его частичного обновления. Частичная информация о заказе должна быть предоставлена в JSON-формате в теле запроса. Поскольку это PATCH-запрос, нам нужно отправить только те поля, которые необходимо обновить, а остальные поля в запросе отправлять не нужно.

Кроме того, в качестве меры безопасности вместе с PATCH-запросом должен быть предоставлен валидный токен аутентификации, иначе запрос не будет выполнен.

Запрос PATCH вернет обновленную информацию о заказе в ответ с кодом состояния (статус-кодом) 200. 

В случае неудачи обновления с помощью запроса PATCH, в зависимости от ситуации будут переданы следующие коды: 

1. Код состояния 404 — Если нет заказа для соответствующего order_id, предоставленных для обновления заказа 
2. Код состояния 400 — Если аутентификация токена не прошла
3. Код состояния 400 — Если в запросе отправлено неправильное тело или нет тела 
4. Код состояния 403 — Если при отправке запроса токен не был предоставлен 

Установка и настройка

В предыдущей части практикума описаны шаги установки и настройки.

Тестируемое приложение

Используем те же бесплатные API restful-ecommerce, доступные на GitHub.

Для частичного обновления заказа будет использоваться PATCH к API — /partialUpdateOrder/{id}.

Сценарий: обновление заказа PATCH-запросом

1. Запустить службу restful-ecommerce 
2. С помощью POST-запроса создать несколько заказов в системе 
3. Обновить product_name, product_amt и qty для order_id “1” 
4. Проверить, что в ответ возвращается код состояния 200 
5. Проверить, что детали заказа обновлены правильно

Реализация теста

Для частичного обновления заказа нам нужно отправить тело запроса с некоторыми полями для обновления, плюс токен авторизации. Этот токен гарантирует, что заказ обновляет валидный пользователь приложения.

Генерация токена

Токен можно сгенерировать с помощью POST к эндпойнту /auth.

Этот эндпойнт (конечная точка) API требует указания учетных данных для логина в теле запроса. Валидные учетные данные для входа следующие: 

• username — «admin»
• password — «secretPass123»

При передаче этих учетных данных API возвращает JWT-токен в ответе с кодом 200:

Мы будем генерировать и применять токен с помощью метода getCredentials() из класса TokenBuilder, который доступен в пакете testdata.

public static TokenData getCredentials() {
    return TokenData.builder().username("admin")
            .password("secretPass123")
            .build();
}

Метод getCredentials() возвращает объект TokenData, содержащий поля username и password.

@Getter
@Builder
public class TokenData {

    private String username;
    private String password;

}

Как только токен сгенерирован, его можно использовать в PATCH-запросе API для частичного обновления заказа.

Генерация тестовых данных обновления заказа

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

Мы добавим новый метод getPartialUpdatedOrder() в существующий класс генератора тестовых данных OrderDataBuilder.

    public static OrderData getPartialUpdatedOrder() {
        return OrderData.builder()
                .productName(FAKER.commerce().productName())
                .productAmount(FAKER.number().numberBetween(550,560))
                .qty(FAKER.number().numberBetween(3, 4))
                .build();

    }

Этот метод будет менять только 3 поля: product_name, product_amount и qty и, соответственно, использовать их для создания нового JSON-объекта, который будет передан в качестве тела запроса в PATCH-запрос к API. 

Обновление заказа PATCH-запросом 

И мы подошли к финальному этапу, на котором мы будем тестировать PATCH-запрос к API в Playwright. 

Создадим новый тестовый метод testShouldPartialUpdateTheOrderUsingPatch() в существующем классе HappyPathTests.

@Test
    public void testShouldPartialUpdateTheOrderUsingPatch() {
    
        final APIResponse authResponse = this.request.post("/auth", RequestOptions.create().setData(getCredentials()));
        final JSONObject authResponseObject = new JSONObject(authResponse.text());

        final String token = authResponseObject.get("token").toString();
        final OrderData partialUpdatedOrder = getPartialUpdatedOrder();

        final int orderId = 1;
        final APIResponse response = this.request.patch("/partialUpdateOrder/" + orderId, RequestOptions.create()
                .setHeader("Authorization", token)
                .setData(partialUpdatedOrder));

        final JSONObject updateOrderResponseObject = new JSONObject(response.text());
        final JSONObject orderObject = updateOrderResponseObject.getJSONObject("order");
        assertEquals(response.status(), 200);
        assertEquals(updateOrderResponseObject.get("message"), "Order updated successfully!");
        assertEquals(orderId, orderObject.get("id"));
        assertEquals(partialUpdatedOrder.getProductAmount(), orderObject.get("product_amount"));
        assertEquals(partialUpdatedOrder.getQty(), orderObject.get("qty"));
    }

Этот метод сначала обратится к Authorization API для генерации токена. Ответ от API авторизации будет сохранен в переменной authResponseObject, которая в дальнейшем будет использована для извлечения значения из поля «token» в ответе.

Тело запроса, которое нужно отправить в PATCH API, будет сгенерировано и сохранено в объекте partialUpdateOrder. Это делается для того, чтобы мы могли использовать этот объект в дальнейшем при проверке ответа.

Далее в методе setHeader() будет установлен токен, а с помощью метода setData() будет отправлен объект тела запроса. Запрос PATCH будет обработан с помощью метода patch() API, который позволит частично обновить заказ. 

Тело ответа:

{
  "message": "Order updated successfully!",
  "order": {
    "id": 1,
    "user_id": "1",
    "product_id": "1",
    "product_name": "Samsung Galaxy S23",
    "product_amount": 5999,
    "qty": 1,
    "tax_amt": 5.99,
    "total_amt": 505.99
  }
}

Ответ, полученный от этого API через PATCH, будет сохранен в переменной response и в дальнейшем использоваться для валидации ответа.

И последний шаг: выполнение тестовых утверждений (ассертов). Ответ от PATCH возвращает JSON-объект, который будет храниться в объекте с именем updateOrderResponseObject. 

Поле message доступно в основном теле ответа, поэтому оно будет ассертом, с помощью updateOrderResponseObject, вызывающего метод get(), который просит вернуть значение поля message.

JSON-объект order будет храниться в объекте с именем orderObject. Ассерты для полей будут выполняться с помощью объекта orderObject. 

Объект partialUpdateOrder, который фактически хранит тело запроса, отправленного для частичного обновления заказа, будет использоваться для ожидаемых значений, а orderObject будет использоваться для фактических значений в конце выполнения ассертов.

Выполнение теста

Создадим новый файл testng.xml — testng-restfulecommerce-partialupdateorder.xml, чтобы выполнить тест последовательно, то есть сначала вызвать тест POST API для генерации заказов, а затем вызвать тест PATCH API для частичного обновления заказа.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Restful ECommerce Test Suite">
    <test name="Testing Happy Path Scenarios of Creating and Updating Orders">
        <classes>
            <class name="io.github.mfaisalkhatri.api.restfulecommerce.HappyPathTests">
                <methods>
                    <include name="testShouldCreateNewOrders"/>
                    <include name="testShouldPartialUpdateTheOrderUsingPatch"/>
                </methods>
            </class>
        </classes>
    </test>
</suite>

Следующий скриншот выполнения теста в IntelliJ IDE показывает, что тесты были выполнены успешно и частичное обновление заказа прошло успешно.

Резюме 

Итак, му узнали, что запросы типа PATCH позволяют частично обновлять запрашиваемый ресурс. PATCH позволяет гибче обновлять конкретный ресурс — только нужные поля.

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

M.F.Khatri