В прошлой статье мы разобрали как можно проверить POST запрос. У нас вышло достаточно много проверок, сейчас продолжим тестировать тот же самой запрос, только теперь метод PUT.
Вновь напишем то же самое ТЗ
Реализовать метод PUT /testmethod/id
- "Medical" - Медицинская организация, которая устанавливает список обязательных услуг из справочника test.medical.id (varchar, обязательный, запись в test.testRestrictions.Mo.
- "Code" - Код услуги из справочника test.medicalcode.code (varchar, обязательный, запись в test.testRestrictions.code)
- "Area" - Анатомическая область из справочника test.anatom.id(varchar, обязательный, запись в test.testRestrictions.area)
- "Documents" - Перечень видов документов (ключ, внутри которого передаётся массив значений varchar, условно обязательный, запись в test.testRestrictions.doc) Передаётся значение поля test.documents.id.
- "Diagnosis" - Код диагноза из справочника test.diagnosis.id, (varchar, не обязательный, запись в test.testRestrictions.diagnosis)
- "lab" - Лабораторный тест из справочника (varchar, обязательный при указании Diagnosis, запись в test.testRestrictions.diagnosis)
- "Value" - Пороговое значение (numeric, обязательный при указании lab, запись в test.testRestrictions.value)
При добавлении записи необходимо проверять наличие в таблице у текущей мо дубли по следующим параметрам:
Medical+ Area + Documents
Medical+ Diagnosis+ lab
По условиям обычно, метод изменения не сильно отличается от метода добавления. Если у нас есть ограничение при добавлении, то при изменении это ограничение не должно ломать логику.
Проверки для PUT запроса
Проверок будет меньше. Мы можем не изощряться как с методом POST. Потому что мы поняли, какие данные принимает сервер, а какие нет.
✅Для начала как и со свеми другими проверками, нужно отправить валидные данные и убедиться что данные добавились в таблицу test.testRestrictions.
🔵 1 проверка.
Результат: данные добавились
✅Проверим как у нас обрабатывается момент, когда мы указываем несуществующий Id записи, то есть той, которой нет в БД.
🔵 1 проверка.
Результат: корректная ошибка, на то что такой записи в БД нет.
✅У нас присутствует уникальное сочетание полей. Не забываем проверить и его.
🔵 1 проверка - отправили Medical+ Area + Documents
🔵 1 проверка - отправили ещё раз Medical+ Area + Documents
🔵 1 проверка - отправили Medical+ Diagnosis+ lab
🔵 1 проверка - отправили ещё раз Medical+ Diagnosis+ lab
Результат: сервер обрабатывает уникальное сочетания, если есть такие в БД, то выводит ошибку.
✅Сейчас также проверим обязательность полей на обновление. Мы можем обновить данные без необязательных и не можем без обязательных.
🔵 1 проверка - без Documents, Diagnosis, lab, Value
🔵 1 проверка - с Diagnosis, но без lab
🔵 1 проверка - с lab, но без Value
🔵 1 проверка - с Value, но без Diagnosis и lab
🔵 1 проверка - без Medical
🔵 1 проверка - без MedicalCode
🔵 1 проверка - без Area
Результат: результаты должны совпадать с ожидаемым результатом. Не должно быть ошибок в логике обязательности полей.
✅Всё также проверяем, но теперь не убираем поле, а прописываем в нём null.
🔵 7 проверок.
Результат: сервер умеет реагировать как и на отсутствие поля, так и на значение null.
✅Как я уже говорил, мы проверяли валидность вводимых значений, 6 из 7 полей идут из других таблиц, так что не получится от балды написать значение. Если есть время и желание, то конечно же можно протестировать. Я обычно в таком случае беру не все поля в проверку, парочку отправляю и смотрю, что да, нельзя изменить табличное значение на выдуманное и иду дальше.
🔵 6 проверок.
Результат: нельзя изменить табличное значение на выдуманное.
И того у нас получилось 26 проверок. Да немного меньше, но мы также полностью проверили все ОР.
Если у вас есть вопросы или вы просто хотите стать частью команды тестировщиков, то переходи в ТГ канал, где можем пообщаться с единомышленниками и найти много интересных и полезных знаний! Также если вам нужна индивидуальная консультация, менторство и помощь в создании проекта пишите в ТГ канал!