Подскажите ресурсы для изучения REST API Test Automation

Теги: #<Tag:0x00007f78ef3d5a80> #<Tag:0x00007f78ef3d5828> #<Tag:0x00007f78ef3d56e8>

Слово непоганий трошки не підходить для цього інструменту, він - аф***нний!

3 симпатии

:smirk: Я им недавно пользуюсь. Так что рекомендовал с осторожностью. Пока по впечатлениям действительно аф***нный!

rest-assured крутой, да. Можно еще посмотреть в сторону Spring RestTemplate, у нас на проекте юзают его для тестирования рестов.

Теория интересует по минимуму. Больше практические вещи, например построение фреймворка. Инструменты - круто, но только это часть проблематики, еще бы добавил RestEasy.
Еще что-то?

Page Object паттерн работает и в случае с REST API Test Automation.
Главные рекомендации как и везде:

  • “разделяй и властвуй”
  • избегать дублирования кода
  • переиспользовать код
  • не усложнять фреймворк, если того не требуется (overengineering)
  • писать короткие и независимые тесты
  • тест должен делать только, то на что он направлен
  • тестовые данные должны создаваться/удалятся наиболее удобным и быстрым способом и отдельно от тесты
4 симпатии

Для python API testing вполне подойдет pytest с его фикстурами.
Особое внимание к хукам, например pytest_generate_tests https://docs.pytest.org/en/latest/parametrize.html#pytest-generate-tests
А здесь Андрей показывает трюки с pytest https://www.youtube.com/watch?v=7KgihdKTWY4
Возможно не ответил на ваш вопрос, но всеобъемлющих python курсов я не нашел.

5 симпатий

Для автоматизации REST API тестирования на Java рекомендую ещё посмотреть и поизучать Feign ( https://github.com/OpenFeign/feign ) и ещё люди советуют Retrofit (http://square.github.io/retrofit/)

На этих штуках можно быстро написать клиента для REST который будет ходить на нужные вам сервисы и конвертировать JSON (как на входе так и на выходе) в Java обьекты
Дальше, комбинируя это с проверками из AssertJ или Hamcrest Matchers можно сделать замечательный фреймворк.

На мой взгляд это более удобно и менее хардкорно чем разбиратся с RestTemplate =)

По сути для автоматизации REST API надо научится этот REST API сначала использовать (вызывать HTTP запросы с параметрами, получать ответ)

1 симпатия

Підтримую Retrofit!!

1 симпатия

С рекомендациями согласен. Можете объяснить, как Page Object применять при работе с REST API?

Одна из главных идей Page Object в случае с WebDriver - это чтобы в тестах не было непосредственно работы с WebDriver. Т.е. Вы создаёте дополнительный уровень абстракции - объекты страниц и в самом тесте работаете с ними (говорите странице сделай то и она возвращает Вам новый объект).
Та же идея и с REST API.
К примеру Вы решили использовать RestAssured.
Идея в том, чтобы в самих тестах не было работы с RestAssured. Надо создать дополнительный уровень абстракции - объект(ы), через который Вы будете работать с API.
Например, у Вас есть REST API по управлению персоналом с методами:

  • создать отдел
  • редактировать отдел
  • удалить отдел
  • найти отдел
  • создать сотрудника
  • редактировать сотрудника
  • удалить сотрудника
  • найти сотрудника
    В таком случае Вы можете создать объект DepartmentService и спрятать у него внутрях вызовы RestAssured по созданию/редактированию/удалению/поиску отделов, а в тесте работать с объектом DepartmentService. Аналогично для сотрудников.
    В этом случае если у вас меняется, например сигнатура вызова API методов, то Вы будете менять внутренности DepartmentService, а тесты трогать не будете.
4 симпатии

А, я понял - Вы имели в виду абстракцию, а не конкретный паттерн.
Меня сбила с толку фраза “Page Object паттерн работает и в случае с REST API” - я вообще не понял как паттерн представления графических страниц может применяться в не-графическом контексте.
Если уже говорить о паттернах - то это скорее “фасад”.

1 симпатия

Да. это и имел ввиду.
Я бы сказал что Page Object - это тоже своего рода фасад. :grinning:
Но не будем заострять внимание на терминах. Главное смысл понятен.

2 симпатии

В случае с Java посмотрите в сторону проверенных библиотек:

Если у вас исключительно тестирование REST, то вот хороший вариант
Тесты пишутся в cucumber

1 симпатия

По библиотекам на Java примерно такой расклад по моему личному опыту
Буду рад выслушать мнения!

  • Jersey - одна из самых низкоуровневых библиотек. Много “boilerplate” - всю логику по работе с REST надо будет писать самому. Обычно работаешь с чем то вроде XPATH по Json дереву
    По мне так самый хардкор для тестировщика. Я бы не пользовал без нужды
  • RestTemplate - если в фреймворке уже используется Spring то хороший вариант, поскольку затягивает его. Меньше кода чем с Jersey - работаешь с Java обьектами а не XPATH. Минусы - есть методы которые делают вроде одно и то же, но не совсем =)
  • RestAssured - фреймворк заточен на тестирование REST (там уже есть свои проверки, given-when-then) и в этом его сила и слабость. Работаешь с некой иерархией обьектов
  • Feign - библиотека от Netflix (а эти чуваки собаку сьели с REST) для быстрого написания REST клиента (изначально заточен под наведение мостов между микросервисами). Все endpoints приложения декларируются в интерфейсе (что удобно). Сам заворачивает json в Java обьекты. Работаешь с Java обьектами и методами
  • Retrofit - тот же концепт что и Feign. Согласно официальному сайту - типобезопасный HTTP-клиент для Android и Java
6 симпатий

Пример работы с Feign

  1. Есть клас перечисляющий REST API методы сервиса
    https://gist.github.com/vjacheslavl/01eea424ec8fe97e7352ed199a50c1a1

  2. Методы работают с Java DTOшками. Я использую Lombok чтобы были уже все билдеры, гетеры, сетеры
    https://gist.github.com/vjacheslavl/8e6950ea328fc2f3937ce2fe5f6fefaa

  3. Создаём Feign клиента (тут у меня в примере немного накручено, прокси там всякие подключал, механизм кодирования/декодирования подстраивал)
    Самое главное что в нём указывается Base Url и наш интерфейс с API методами
    https://gist.github.com/vjacheslavl/a1a886ecb3e29a447972758cecfa8b6f

  4. Сами тесты будут выглядеть так
    https://gist.github.com/vjacheslavl/ed2380a18973ec2a4d8e1bee89441ad9

  5. Пример помника под эту красотулю
    https://gist.github.com/vjacheslavl/3d8d161d601183bc704c5da133999007

1 симпатия

Java Binding и serialization в помощь к Джерси, мессадж провайдеры и оный хлам. Тогда не надо будет никаких X-path или JPath))))
Работать надо напрямую с джава обьектами десериализованными из респонза. Как в примере с Spring RestTemplate ну и похоже Feign нечто такое.
Как правило библиотеки дающие “почти все” из коробки рано или поздно дают течь и потом приходиться либо самому фиксить баги и деплоить свои артефакты используемых либ либо долго и нудно ждать фикса от разрабов ну или самому законтрибьютить в нужный репо и релизнуть билд.
Но это мое мнение. Решать вам.
Сам использую cxf. Жалоб нет)

Да. Замечательный пример. Именно такую иерархию и структурирование стоит использовать в самом начале. Грамотно разделить все в начале и разумно построить последующие шаги. У меня была ошибка что попытался в самом начале написания фреймворка решил слепить никальный метод для отправки запросов. Получилось так что сейчас борюсь чтобы на лету менять содержимое body, что крайне неудобно если само тело запроса не собирается как объект а выдергивается из файла. Все начинающим, и продолжающим копать советую быть предельно осторожными.

Чем он лучше любого хттп клиента + assertJ ?

Сам еще не пробовал, но есть еще Citrus Framework - это для Java.
На C# в основном используется встроенный HttpClient, плюс есть еще отдельный пакет - RestSharp.