Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Как тестировать REST API?

soapui
rest
soap
Теги: #<Tag:0x00007f7b64b74490> #<Tag:0x00007f7b64b74300> #<Tag:0x00007f7b64b74148>

(Batyar) #1

Помогите пожалуйста кто сталкивался с REST API для сайта и его тестированием. Как можно его протестировать простими GET и POST запросами с помощю SOAP UI и без него.

 


(Taras) #2

я сталкивался, SOAP UI - там добавляешь REST project - тип риквестов итд, парсить JSON можно написав простие манипуляции на Java или Groovy.

Так же подойдет простая библиотека Apache http client - джавишная, там просто создаешь Client-а, ему метод запроса, екзекютаешь етот запрос, и парсишь респонс.

 


(Mykhailo Poliarush) #3

по SoapUI очень просто можно манипулировать REST web-services 

http://www.soapui.org/REST-Testing/getting-started.html


(Mykhailo Poliarush) #4

кстати вот есть еще одна хорошая ссылка, который нашел буквально сегодня

https://twitter.com/mpoliarush/status/245779261280096256


(Ninfea) #5

А кто не хочет использовать soapUI), какие посоветуете библиотеки, фреймворки?
Кто чем пользуется?


#6

а какой язык программирования?


(Ninfea) #7

ну лучше java, но могу смерится и с python)


(sidelnikovmike) #8

Apache HttpClient ну и далее в путь.
Вот есть примеры даже на официальном сайте


(apetrovskiy) #9

Речь идёт о клиентской части?
Странно, на этом портале как-то не любят Spring. А между тем, Spring (и Spring.NET)

  • предоставляют RestTemplate, позволяющий избежать кучи повторяющегося boilerplate кода
  • джавовская версия предлагает RestTemplate для Android
  • есть даже встроенные средства тестирования (я вообще не люблю фреймворки, с которыми не идут в комплекте средства написания тестов) - т.е. вы можете протестировать ваш тестовый фреймворк юнит-тестами, “за копейки”.

И Spring, и Spring.NET популярны (представитель EMC говорил в 2009-м году, что половина корпоративных приложений в мире пишется не на спринг), есть книги, блоги, видео, документация. Работает то ли с пятой, то ли с шестой джавы.
Из книг рекомендую Spring In Action, Pro Spring 3 (в этой области, т.е. RestTemplate, код совместим со спринг 4) - имею обе в бумаге и доволен.

Штатные доки, гайды (примеры), конкретно по RestTemplate: вот, вот, вот.
Полезные рассылки и статьи.
Лично я начинал с указанных двух книг, после чего с лёгкостью перешёл на Spring.NET - код почти один в один с джавовским.
Мои примеры на Spring.NET (код как близнец джавовскому Spring).

Для серверной части я использую другой замечательный фреймворк .NET/Mono, прямых аналогов которому нет на джаве. Тоже с интегрированной поддержкой тестов и т.д.

Джавовский Spring-код хорошо пишется в STS или в eclipse с установленной STS.


#10

Если Java окружение, то можно кроме упомянутого Apache Client использовать HTTP Builder + Groovy


(Ninfea) #11

Да, речь идет о клиентской части. Составления сложных тестов, например, создание нового юзера на сайте или восстановление пароля.
Но как то я не готова на Spring, даже не могу ответить почему)


(sidelnikovmike) #12

И правильно. Спринг упрощает усложняя.


(Sergey Korol) #13

Вот еще Jersey. И пример клиента.


(Ninfea) #14

А никто не работал с http://http.jcabi.com/ или https://code.google.com/p/rest-assured/wiki/GettingStarted ?


(Sergey Korol) #15

По синтаксису очень похож на Jersey 2.x. Не уверен, почему автор считает свой клиент лучше и проще. Возможно следует более детально изучить его доки / примеры.


(apetrovskiy) #16

И правильно. Спринг упрощает усложняя.

А о каком усложнении идёт речь? Никто же не заставляет все объекты тестового кода получать из Spring.IoC или оборачивать Spring.AOP. Это имеет смысл для фреймворков, а не для “просто кода теста”.

Больше линков, меньше слов: пример 2.7.1:
из четырёх строк кода, первые три находятся где-то в общем коде, а сам запрос - это restTemplate.getForObject(…)

пример 2.7.3: создание шаблона и добавление конвертера опять же в общем коде, сам вызов - это установка хэдеров, запрос и преобразование результатов (5 строк).

имхо вполне себе компактно и код читаемый.


(apetrovskiy) #17

А мне вот интересно, как тестировщики “запасаются” объектами для тестирования через REST.
Если интерфейсы не даны (нет доступа к исходникам, или работа идёт с клиента, который не поддерживает интерфейсы сервера), можно создать объекты двумя способами:

  1. написать в виде строк, текстовых файлов, и т.д., затем десериализовать и отправить. Ну или отправить в “строчном” виде через некий тул/фреймворк. Хранение данных в виде строчных данных.
  2. самому написать интерфейсы, создать на их основе экземпляры объектов, заполнить данными и отправить на сервер. Хранение данных в коде.

Интересно, каким способом сейчас пользуются.


(German Komashko) #18

Это возможно не поможет решению вашей проблемы, но быть может послужит подручным инструментом:


(apetrovskiy) #19

Если говорить о Chrome, то я предпочитаю DHC - не самый навороченный из доступных в Chrome и Firefox, но понравился в использовании.


(sidelnikovmike) #20

Ну как видно из ссылки вашей - спринговая библиотека использует httpclient , который собственно я и советовал. Его использование тоже очень просто - строк не много, но зато не обернуто в тысячи тысяч фабрик и тп , как это любят делать в спринге. Что приводит к тому, что - да, удобно, но сути , как это реально работает - без пол литра(хорошго понимания java) не разберешься. А (это мое мнение) - понимание, что делает каждая строчка вашего кода - это признак действительно хорошего специалиста.

Плюс при подключении спринга очень часто тянется куча куча кода, который по сути то и не нужен.

Я предлагаю не разводить здесь обсуждение - спринг или не спринг.