Home

Автор: Кристин Джеквони (Kristin Jackvony)

Оригинал статьи

Перевод: Ольга Алифанова.

Сегодня мы обсудим тестирование PUT-запросов. В целом они очень похожи на POST-запросы – основное отличие в том, что POST создает новую запись, а PUT заменяют существующую.

Вернемся в Swagger Pet Store, чтобы разобраться, как создавать PUT-запрос. Кликните по запросу PUT /pet, чтобы открыть его:

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

{
  "id": 1,
  "category": {
    "id": 1,
    "name": "Cat"
  },
  "name": "Grumpy Cat",
  "photoUrls": [
    "https://pbs.twimg.com/profile_images/948294484596375552/RyGNqDEM_400x400.jpg"
  ],
  "tags": [
    {
      "id": 1,
      "name": "Mixed breed"
    }
  ],
  "status": "available"
}

Теперь сделайте GET-запрос, чтобы убедиться, что питомец правильно добавился. А теперь сделаем PUT-запрос с вот такими значениями:

{
  "id": 1,
  "category": {
    "id": 2,
    "name": "Dog"
  },
  "name": "Droopy Dog",
  "photoUrls": [
    "https://upload.wikimedia.org/wikipedia/en/thumb/f/fd/Droopy_dog.png/150px-Droopy_dog.png"
  ],
  "tags": [
    {
      "id": 2,
      "name": "Beagle"
    }
  ],
  "status": "pending"
}

Заметьте, что все значения в теле запроса изменены, кроме id питомца. После отправки запроса выполните GET, чтобы убедиться, что значения изменились.

PUT-запрос всегда заменяет ВСЕ значения во всей записи, и это значит, что если каких-то значений не хватает – они будут удалены. К примеру, если мы делаем PUT-запрос для того же ID, включающий только имя и адрес фотографии, то это все, что сохранит сервер. Тэги, статус, и все остальное удалится.

Чтобы разобраться в тестировании PUT-запросов, я забуду на минутку про Swagger Pet Store и приведу другой пример. Предположим, у нас есть приложение, хранящее список сотрудников. Оно пишет данные в таблицу с такими значениями:

PUT-запрос для обновления записи в этой таблице будет выглядеть так:

{
  "firstName": "Amy",
  "lastName": "Miller"
}

URL этого запроса будет таким: app/employee/1. В этом приложении id сотрудника передается через URL, а не в теле запроса (это довольно распространенная практика).

Начнем мы тестирование этого воображаемого приложения со "счастливого пути": если мы отправим этот запрос, изменится ли имя сотрудника номер 1 на Эми Миллер с Фреда Смита? Это можно проверить, напрямую запросив базу данных, или использовав GET-запрос.

Затем мы посмотрим, что будет, если отправить PUT-запрос для записи, которой не существует. Представьте аналогичный запрос, где вместо URL app/employee/1 используется URL app/employee/3. Как можно увидеть в табличке, записи 3 не существует. Запрос должен вернуть ошибку – например, 404 Not Found. Можно также передать бессмысленные id (буквы, слова, символы), и вообще их не передать. Все эти запросы должны возвращать соответствующие ошибки.

Теперь давайте обратимся к телу нашего запроса. Представьте, что firstName и lastName – необходимые для запроса поля. Мы должны получить сообщение об ошибке, если передали пустое тело, или только имя, или только фамилию. В сценарии, где полей гораздо больше, чем у нас, стоит проверить множество различных комбинаций, где отсутствуют различные обязательные и необязательные поля.

Как я уже упоминала, PUT-запросы должны заменять ВСЕ значения в записи: она как будто бы полностью удалялась и была заменена на абсолютно новую. Представим сценарий, в котором firstName – необязательное поле, а запись 1 выглядит как Amy Miller. Если мы проведем тест с отправкой только lastName ("Brown"), у записи 1 должна появиться пустота в поле firstName, а lastName должно измениться на Brown.

Также можно посмотреть, что будет, если попробовать передать запрос с полями, которых вообще нет в таблице! К примеру, вот так:

{
  "firstName": "Amy",
  "middleName": "Jo"
  "lastName": "Miller"
}

Убедитесь, что или это поле будет проигнорировано, или вы получите сообщение об ошибке.

Теперь мы можем перейти к тестированию отдельных полей. Какие значения в них разрешены? Есть ли ограничения по количеству символов? Стоит протестировать каждое поле, чтобы убедиться, что вы получаете соответствующее сообщение об ошибке при нарушении ограничений, а также при передаче недопустимых символов или значений. Можно также попробовать отправить значения, которые можно использовать для внедрения сценариев или SQL-инъекций: они должны или отвергаться, или очищаться, чтобы вредоносная атака не сработала.

И, наконец, можно поиграть с HTTP-глаголом и запросом в целом. Что будет, если поменять PUT на POST? В нашем гипотетическом приложении POST-запрос с URL app/employee/1 вернет ошибку 409, потому что запись с таким id уже существует. Можно также посмотреть, что произойдет, если удалить или поменять необходимые заголовки в запросе.

Надеюсь, что эта статья дала вам представление о поведении PUT-запросов и способов их протестировать.

Больше информации по этой теме вы можете получить в курсе Тестирование REST API

Предыдущие статьи на эту тему

Введение в REST-запросы и тестирование GET-запросов

Тестирование POST-запросов

Обсудить статью в форуме