Если вы хоть раз делали REST-запрос или изучали раздел инструментов разработчика в браузере, то наверняка видели код ответа из трех цифр, возвращенный в ответ на HTTP-запрос. Давайте поговорим о различных типах кодов ответа, которые можно получить в процессе тестирования API, и том, что они означают.
Сегодня мы закончим обсуждение типов REST-запросов, разобрав DELETE-запрос и специфику его тестирования. Мы также узнаем, как создать цепочку REST-запросов в коллекции Postman.
Как и PUT-запросы, PATCH-запросы меняют существующую запись, однако их куда сложнее тестировать! PUT-запрос меняет запись целиком, а PATCH – только одну часть запроса. С PATCH-запросом можно проводить множество различных операций – вы можете добавлять, заменять, удалять, копировать и перемещать значения в вашей записи. Опишу несколько примеров, а потом поговорим о том, как это тестировать.
Этот ретроспективный урок автоматизации посвящен ее моделям. Когда мы говорим "модель" или "смоделировать", мы обычно имеем в виду "трехмерное представление персоны или вещи или структуры, обычно имеющее меньший в сравнении с оригиналом масштаб" (случайное определение из Google, к счастью, верное).
Говоря о моделировании автоматизации, мы подразумеваем представление структуры автоматизированных проверок, которые мы проводим, и их распределение по разным слоям.
Сегодня мы обсудим тестирование PUT-запросов. В целом они очень похожи на POST-запросы – основное отличие в том, что POST создает новую запись, а PUT заменяют существующую.
Вернемся в Swagger Pet Store, чтобы разобраться, как создавать PUT-запрос. Кликните по запросу PUT /pet, чтобы открыть его:
Представьте, что перед Вами поставили задачу: протестировать API веб-сервиса. На этом этапе возникает довольно много вопросов, начиная от “Что именно требуется протестировать? Функционал? Нагрузку? Юзабилити?” до “Чем отличается список проверок для тестирования API от чек-листа для проверки UI”? В данной статье я поделюсь своим опытом составления проверок и кейсов для функционального тестирования SOAP API крупного государственного проекта со сложной логикой; мы обсудим, как лучше писать проверки и на что следует обратить особое внимание; в конце я представлю примерный вид документа с результатами тест-дизайна, которым будет удобно пользоваться и который не стыдно показать менеджеру или заказчику.
Публикуем запись доклада Антонины Фанталиной "Автоматизация регресса бекендов. Без СМС и автотестов" с прошедшего в Новосибирске QA DevDay.
Тоня тестирует навигатор в 2ГИС. Проект объёмный, а имеющиеся unit-/функциональные/интеграционные тесты не всегда находят проблемы. В своём выступление Тоня рассказала, как проверить API на изменения с помощью diff-ответов от сервера, и поделилась муками выбора между Diffy, Karate и кастомным решением.
Сегодня мы рассмотрим POST-запросы. Они, пожалуй, наиболее важные из всех REST-запросов, потому что добавляют новые записи в базу данных приложения. Очень важно как следует их протестировать, потому что они напрямую влияют на качество данных вашей базы.
Усилия по тестированию прилагаются на различных уровнях автоматизации в приложении. Вот некоторые из них, которые я, согласно личному опыту, нахожу интересными:
Автоматизация на юнит-уровне – она редко касается кого-либо, кроме разработчиков, и я считаю, что это правильно. В норме цель юнит-тестов – это предоставление быстрой обратной связи о правильности работы кода. Конечно, они подвержены тем же болезням, что и автоматизация в целом – "утверждающе-демонстративному" образу мышления при создании тестов. Даже если тесты используются в методологии управления через тестирование, они не особенно полезны, если сообщают только о том, что продукт работает. Фактически любой тест, который не подвергает систему суровым испытаниям с целью выявления проблем – это просто показуха.
Тут важно помнить, что очень глупо полагать, что наличие юнит-тестов означает, что что-то вообще тестировалось, или же что нужда в других уровнях тестирования благодаря наличию юнит-тестов снизилась. Юнит-тесты просто сообщают, что наш код готов двигаться дальше по цепочке тестирования. Не больше, не меньше!
