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

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

• Успешное обновление:

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

• Неуспешное обновление (негативные тесты):

  • Невалидные данные:

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

  • Несуществующий ресурс:

    • PUT запрос с ID, которого нет в системе.

  • Конфликт данных:

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

  • Недостаток прав:

    • Попытка обновить ресурс без соответствующих прав доступа.

  • Валидационные ошибки:

    • Нарушение бизнес-логики или ограничений базы данных (например, дублирование уникального значения).

  • Неверный Content-Type:

    • Отправка запроса с Content-Type, отличным от ожидаемого (например, text/plain вместо application/json).

  • Пустое тело запроса:

    • Отправка запроса без тела.

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

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

Пример структуры тестовых случаев:

Для автоматизации использовал бы фреймворки типа RestAssured (Java), Requests (Python) или Supertest (Node.js) и инструменты для генерации тестовых данных.