Сегодня мы закончим обсуждение типов 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-запросов, потому что добавляют новые записи в базу данных приложения. Очень важно как следует их протестировать, потому что они напрямую влияют на качество данных вашей базы.
Усилия по тестированию прилагаются на различных уровнях автоматизации в приложении. Вот некоторые из них, которые я, согласно личному опыту, нахожу интересными:
Автоматизация на юнит-уровне – она редко касается кого-либо, кроме разработчиков, и я считаю, что это правильно. В норме цель юнит-тестов – это предоставление быстрой обратной связи о правильности работы кода. Конечно, они подвержены тем же болезням, что и автоматизация в целом – "утверждающе-демонстративному" образу мышления при создании тестов. Даже если тесты используются в методологии управления через тестирование, они не особенно полезны, если сообщают только о том, что продукт работает. Фактически любой тест, который не подвергает систему суровым испытаниям с целью выявления проблем – это просто показуха.
Тут важно помнить, что очень глупо полагать, что наличие юнит-тестов означает, что что-то вообще тестировалось, или же что нужда в других уровнях тестирования благодаря наличию юнит-тестов снизилась. Юнит-тесты просто сообщают, что наш код готов двигаться дальше по цепочке тестирования. Не больше, не меньше!
Все больше и больше компаний переходит на микросервисы в своих приложениях. Это означает, что разные секции приложения могут иметь отдельные хранилища данных и отдельные команды для взаимодействия с ними. Преимущество такого подхода в том, что в небольшой компонент внедрять изменения куда проще, нежели менять все приложение. Это также означает, что если упадет один микросервис, оставшаяся часть приложения продолжит функционировать. К примеру, представьте, что у вас есть сайт проката велосипедов. У него есть микросервис системы бронирования, и еще один – для учета оборудования. Если микросервис оборудования упадет, пользователи все равно смогут бронировать велосипеды, используя кэшированные данные сервиса оборудования.
Большинство микросервисов используют API – программные интерфейсы приложения, которые представляют собой наборы команд, описывающих, как можно использовать службу. Большая часть API использует REST-запросы (Representational State Transfer — «передача состояния представления») для отправки и получения данных.
Однако, несмотря на широкое применение REST API в современных приложениях, многие тестировщики даже не подозревают, как легко их тестировать! Эта статья – введение в REST-запросы и их использование в тестировании API.
