testomat.io управление авто тестамиПодскажите, плиз, наиболее толковые ресурсы для самостоятельного изучения API Test Automation.
Более всего интересует Java related, но не только.
Тонны Selenium Test Automation ресурсов, но не API Test Automation
На русском или английском. Спасибо
Интересует теория или же инструменты? Если инструменты - то вот неплохой http://rest-assured.io/
5 лайков
Слово непоганий трошки не підходить для цього інструменту, він - аф***нний!
3 лайка
Я им недавно пользуюсь. Так что рекомендовал с осторожностью. Пока по впечатлениям действительно аф***нный!
rest-assured крутой, да. Можно еще посмотреть в сторону Spring RestTemplate, у нас на проекте юзают его для тестирования рестов.
Теория интересует по минимуму. Больше практические вещи, например построение фреймворка. Инструменты - круто, но только это часть проблематики, еще бы добавил RestEasy.
Еще что-то?
Page Object паттерн работает и в случае с REST API Test Automation.
Главные рекомендации как и везде:
- “разделяй и властвуй”
- избегать дублирования кода
- переиспользовать код
- не усложнять фреймворк, если того не требуется (overengineering)
- писать короткие и независимые тесты
- тест должен делать только, то на что он направлен
- тестовые данные должны создаваться/удалятся наиболее удобным и быстрым способом и отдельно от тесты
4 лайка
Для python API testing вполне подойдет pytest с его фикстурами.
Особое внимание к хукам, например pytest_generate_tests How to parametrize fixtures and test functions — pytest documentation
А здесь Андрей показывает трюки с pytest https://www.youtube.com/watch?v=7KgihdKTWY4
Возможно не ответил на ваш вопрос, но всеобъемлющих python курсов я не нашел.
5 лайков
Для автоматизации REST API тестирования на Java рекомендую ещё посмотреть и поизучать Feign ( GitHub - OpenFeign/feign: Feign makes writing java http clients easier ) и ещё люди советуют Retrofit (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 - это тоже своего рода фасад. 
Но не будем заострять внимание на терминах. Главное смысл понятен.
2 лайка
В случае с Java посмотрите в сторону проверенных библиотек:
- apache cxf(SOAP/REST) - http://cxf.apache.org/
- Jersey - REST with Java (JAX-RS) using Jersey - Tutorial
Должно хватить. Полюбому прийдется лепить свои врапперы/клиентские апи/модели для каждого веб сервиса и оперировать уже ими.
Если у вас исключительно тестирование 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
-
Есть клас перечисляющий REST API методы сервиса
ApplicationEndpoints.java · GitHub -
Методы работают с Java DTOшками. Я использую Lombok чтобы были уже все билдеры, гетеры, сетеры
UserPayload.java · GitHub -
Создаём Feign клиента (тут у меня в примере немного накручено, прокси там всякие подключал, механизм кодирования/декодирования подстраивал)
Самое главное что в нём указывается Base Url и наш интерфейс с API методами
RestClient.java · GitHub -
Сами тесты будут выглядеть так
RestTest.java · GitHub -
Пример помника под эту красотулю
pom.xml · GitHub
1 лайк
Java Binding и serialization в помощь к Джерси, мессадж провайдеры и оный хлам. Тогда не надо будет никаких X-path или JPath))))
Работать надо напрямую с джава обьектами десериализованными из респонза. Как в примере с Spring RestTemplate ну и похоже Feign нечто такое.
Как правило библиотеки дающие “почти все” из коробки рано или поздно дают течь и потом приходиться либо самому фиксить баги и деплоить свои артефакты используемых либ либо долго и нудно ждать фикса от разрабов ну или самому законтрибьютить в нужный репо и релизнуть билд.
Но это мое мнение. Решать вам.
Сам использую cxf. Жалоб нет)
Да. Замечательный пример. Именно такую иерархию и структурирование стоит использовать в самом начале. Грамотно разделить все в начале и разумно построить последующие шаги. У меня была ошибка что попытался в самом начале написания фреймворка решил слепить никальный метод для отправки запросов. Получилось так что сейчас борюсь чтобы на лету менять содержимое body, что крайне неудобно если само тело запроса не собирается как объект а выдергивается из файла. Все начинающим, и продолжающим копать советую быть предельно осторожными.