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

Особенности DELETE

DELETE удаляет указанный ресурс с сервера. В идеале в DELETE-запросе отсутствует тело ответа. 

Ресурс указывается URI, и сервер удаляет его безвозвратно. Запросы DELETE не считаются ни безопасными, ни идемпотентными, поскольку они могут вызывать нежелательные эффекты на сервере, например удаление данных из БД. 

Ниже перечислены некоторые ограничения DELETE:

  1. Данные, удаленные с помощью DELETE, необратимы, поэтому с ними следует обращаться осторожно. 
  2. Этот метод не считается безопасным, поскольку он может напрямую удалить ресурс из БД, вызывая конфликты в системе. 
  3. Этот метод не является идемпотентным, то есть его вызов несколько раз для одного и того же ресурса может привести к различным состояниям. Например, в первом случае при вызове DELETE будет возвращен статус-код 204, сообщающий, что ресурс удален, а при повторном вызове DELETE для того же ресурса может быть выдан код 404 NOT FOUND, так как ресурс уже удален.

Ниже приведен пример DELETE-запроса к конечной точке API в проекте restful-ecommerce (как и в предыдущих частях туториала, этот проект будет использоваться в демонстрационных целях.

DELETE /deleteOrder/{id} — Удаление заказа по идентификатору (ID)

Этот API требует указания order_id в качестве параметра Path для поиска соответствующего заказа и его удаления. В этом запросе не требуется предоставлять тело запроса. Однако в качестве меры безопасности для удаления заказа необходимо предоставить token в качестве заголовка header

Запрос удаляет указанный заказ из системы и возвращает код состояния 204

Если заказ не найден или токен не действителен? или не предоставлен, будет выдан следующий ответ: 

  1. Код состояния 400 — Если не удалось аутентифицировать токен 
  2. Код состояния  404 — Если в системе не найден заказ с заданным order_id 
  3. Код состояния 403 — Если токен отсутствует в запросе

Автоматизация тестирования API мы выполняем в Playwright на Java, поскольку в Playwright есть соответствующие методы, которые удобно использовать для в сценариях. 

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

В предыдущих частях блога подробно описаны установка и настройка Playwright на Java. Продолжаем использовать бесплатные API restful-ecommerce на GitHub.

Сценарий тестирования 1 — Удаление валидного заказа

  1. Запустить службу restful-ecommerce 
  2. С помощью POST-запроса создаем несколько заказов в системе 
  3. Удаляем заказ с order_id "1" DELETE-запросом
  4. Проверяем, что в ответ возвращается статус-код 200.

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

Для реализации этого сценария необходимо выполнить следующие шаги: 

  1. Добавить новые заказы с помощью POST-запроса
  2. Обратиться к API /auth для генерации токена 
  3. Обратиться к конечной точке API /deleteOrder/ с токеном и order_id для удаления заказа. 

В существующем тестовом классе HappyPathTests создается новый тестовый метод — testShouldDeleteTheOrder(). Этот метод выполняет все 3 шага, описанных выше.

    @Test
    public void testShouldDeleteTheOrder() {

        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 int orderId = 1;
        final APIResponse response = this.request.delete("/deleteOrder/" + orderId, RequestOptions.create()
                .setHeader("Authorization", token));
        
        assertEquals(response.status(), 204);
    }

Сначала вызывается конечная точка API, через POST /auth, чтобы сгенерировать токен и использовать его далее в тесте. Полученный в ответ токен сохраняется в переменной token. Эта переменная будет далее использоваться в тесте для выполнения DELETE-запроса.

Далее будут созданы новые заказы с помощью метода testShouldCreateNewOrders(), который уже обсуждался в части туториала, посвященной POST-запросам

После того как заказы создались, следующим шагом будет выполнение DELETE-запроса с валидным order_id:

Мы будем удалять заказ с идентификатором order_id «1». Метод delete(), предоставляемый Playwright, удалит ресурс.

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

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

Создаем новый testng.xml с именем «testng-restfulecommerce-deleteorders.xml«. Этот xml-файл позволит выполнять тесты в соответствии с приоритетом, который мы в нем определим.

<?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="testShouldDeleteTheOrder"/>
                </methods>
            </class>
        </classes>
    </test>
</suite>

Итак, первым будет выполнен тестовый метод testShouldCreateNewOrders(), который создаст новые заказы. Далее будет выполнен тестовый метод testShouldDeleteTheOrder() для проверки удаления заказов. 

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

Теперь проверим, что заказ был удален правильно, написав новый тест, который вызовет конечную точку API через GET /getOrder с удаленным order_id.

Сценарий теста 2 — Восстановление удаленного заказа 

  1. Удалить валидный заказ с order_id = "1" 
  2. С помощью API GET /getOrder попробуем восстановить заказ с order_id = "1" 
  3. Проверяем, что возвращается статус-код 404 с сообщением «Заказ с заданными параметрами не найден!«

Реализация

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

    @Test
    public void testShouldNotRetrieveDeletedOrder() {
        final int orderId = 1;
        final APIResponse response = this.request.get("/getOrder", RequestOptions.create().setQueryParam("id", orderId));

        assertEquals(response.status(), 404);

        final JSONObject jsonObject = new JSONObject(response.text());
        assertEquals(jsonObject.get("message"), "No Order found with the given parameters!");
    }

Реализация этого сценария довольно проста: мы будем выполнять GET /getOrder и получать удаленный заказ с order_id «1». 

Далее применяются проверки, что GET возвращает статус-код 404 с сообщением «Заказ с заданными параметрами не найден!«. 

Этот тест гарантирует, что API удаления заказа сработал нормально и заказ был удален из системы. 

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

Обновим файл testng.xml, добавив этот тест в конец файла, после теста удаления:

<?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="testShouldDeleteTheOrder"/>
                    <include name="testShouldNotRetrieveDeletedOrder"/>
                </methods>
            </class>
        </classes>
    </test>
</suite>

Теперь все три теста должны выполняться последовательно. Первый создаст заказы, второй удалит заказ с order_id «1», а последний тест при помощи GET-запроса получит заказ с order_id «1», вернув статус-код 404.

На скриншоте видим, что все три теста выполнены успешно. 

Резюме 

Запросы DELETE позволяют удалить ресурс из системы. Поскольку удаление является важной CRUD-функцией, важно протестировать ее и убедиться, что система работает как положено. Следует помнить, что DELETE — необратимый процесс, поэтому его всегда следует использовать с осторожностью. 

M.S.Faisal


Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас