Приведи пример, как бы ты выбирал тест-кейсы для PUT-запроса.

Выбор тест-кейсов для PUT-запроса направлен на проверку корректного обновления ресурса, обработки различных типов данных и негативных сценариев.

Примеры тест-кейсов:

1. Позитивный сценарий (успешное обновление):

   • Обновление ресурса со всеми валидными полями.
   • Обновление ресурса только с частью валидных полей (если API позволяет частичное обновление).
   • Обновление полей разными типами данных (строки, числа, булевы значения), если это предусмотрено схемой.
   • Обновление ресурса с минимально допустимыми значениями (если применимо).
   • Обновление ресурса с максимально допустимыми значениями (если применимо).

2. Негативные сценарии (ошибки и исключения):

   • Попытка обновить несуществующий ресурс. Ожидаемый ответ: 404 Not Found.
   • Отправка запроса без тела. Ожидаемый ответ: 400 Bad Request или 422 Unprocessable Entity.
   • Отправка запроса с невалидным форматом тела (например, невалидный JSON). Ожидаемый ответ: 400 Bad Request.
   • Отправка запроса с некорректными типами данных для полей. Например, строка вместо числа. Ожидаемый ответ: 400 Bad Request или 422 Unprocessable Entity.
   • Отправка запроса с обязательными полями, пропущенными в теле запроса. Ожидаемый ответ: 400 Bad Request или 422 Unprocessable Entity.
   • Отправка запроса с полями, превышающими допустимую длину/диапазон. Ожидаемый ответ: 400 Bad Request или 422 Unprocessable Entity.
   • Отправка запроса с невалидным значением в пути (например, невалидный ID). Ожидаемый ответ: 400 Bad Request или 404 Not Found.
   • Попытка обновить заблокированный или недоступный ресурс (если применимо). Ожидаемый ответ: 403 Forbidden или 409 Conflict.
   • Отправка запроса с некорректными заголовками (например, Content-Type). Ожидаемый ответ: 415 Unsupported Media Type или 400 Bad Request.
   • Обновление с использованием специальных символов или emoji в строковых полях.

3. Граничные условия:

   • Обновление полей с граничными значениями (например, минимальная/максимальная дата, граничные числа).
   • Обновление полей с пустыми строками или null значениями (если это допустимо).

4. Сценарии параллельного доступа:

   • Одновременная попытка обновить один и тот же ресурс из нескольких источников (если актуально для тестируемой системы).

5. Проверка последствий обновления:

   • Проверка, что данные корректно обновились в базе данных или других системах.
   • Проверка, что зависимые ресурсы или данные были обновлены/изменены соответствующим образом (при наличии зависимостей).
   • Проверка, что GET-запрос к обновленному ресурсу возвращает актуальные данные.
   • Проверка, что другие операции (DELETE, POST) с обновленным ресурсом работают корректно.

Критерии выбора конкретных тест-кейсов зависят от спецификации API, бизнес-требований, анализа рисков и приоритетов. Используется техника тест-дизайна, такая как эквивалентное разбиение и анализ граничных значений, для определения наиболее показательных вариантов входных данных.