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

Архитектура тестового фреймворка для REST сервиса

rest
webservices
framework
page-object
Теги: #<Tag:0x00007f7b646835d0> #<Tag:0x00007f7b64683490> #<Tag:0x00007f7b64683350> #<Tag:0x00007f7b64683210>

#1

Всем привет.
Я абсолютно полный новичок в тестировании веб сервисов, и только-только успел немного изучить и понять что это такое, зачем и с чем, так сказать, едят. Сейчас хочу попробовать на практике непосредственно тестирование этих самых сервисов, но одновременно с этим стал вопрос: как организовать архитектуру тестового фреймворка, в котором будет тестироваться тот или иной сервис?
Как организовать простейший фреймворк для тестирования UI веб приложения - с этим все понятно: здесь будет связка Page Object + тесты + хелперы, а также прочие вспомогательные/служебные слои архитектуры фреймворка в зависимости от конкретного проекта.

По аналогии с вышеописанным все никак не могу понять, как лучше построить архитектуру фреймворка (самописного) для тестирования API какого-нибудь широко известного ресурса, например, Google Maps или Twitter.


(Taras) #2

напишите сначала несколько тестов на SOAP UI, а потом можно самописно делать посложнее , если опита нету


(Taras) #3

если говорить о Java i REST - то есть отличная либа REST-Assured с помощью которой ви сможете разбить ваш фреймворк на компонети очень просто


#4

Подскажите, как в этом фреймворке перенаправить вывод лога куда то кроме консоли?

Rest assured отличный фреймворк, вот документация по нему, там достаточно хорошо все описано

https://github.com/jayway/rest-assured/wiki/Usage


#5

На соап я уже уже пробовал.


(sidelnikovmike) #6

Rest assured может быть и неплохая, но есть ряд минусов

  • проблема с логом - как-то в разумном виде это выводить куда-то - очень сложно

  • есть ряд багов, которые не позволяют делать полноценное покрытие в некоторых случаях

  • тяжеловесная(поглядите в исходники - 10000-строковые груви классы и тд)

  • слишком сильно фреймворк завязывается на rest assured объекты.

  • результаты встроенных проверок читать иногда ооочень сложно.

Имхо, всё таки не стоит запихивать в одну библиотеку и посылку запросов, и инструмент для проверки.
Я у себя сделал небольшую обвязку над apache httpclient (чем собственно и является монтсруозный rest assured) - получилось менее 10 небольших классиков(включая доменную модель и различные логгеры(консоль в том числе).

Очень советую всё таки перед ее использованием попробовать что-то другое.
Для посылки - http client
для проверки данных - тестовый фреймворк типа junit или testng(какой вы используете на проекте).


(toyen) #7

Я теж нещодавно почала вивчення сервісів. І мені дали класне завдання: написати два сервіса REST і SOAP, які реалізують функціональність калькулятора. А потім написати декілька тестів, які ці сервіси тестують. По завданню мені потрібно було використувувати Apache CFX. Спробуйте так.
Ось декілька лінків, які мені допомогли:
http://www.javatips.net/blog/2012/04/expose-cxf-service-with-rest-and-soap
http://www.javatips.net/blog/2012/02/cxf-restful-client
http://www.javatips.net/blog/2011/09/create-cxf-client
https://angelozerr.wordpress.com/2011/08/24/jaxwscxf_step2/#WSHelloServiceImpl


(Sergey Pirogov) #8

а выложить это? или заделиться не? =)


(sidelnikovmike) #9

Не поверите- всё хочу, но руки тупо не доходят. Обязательно выложу и опишу. С большой радостью.


#10

Вялікі дзякуй :slight_smile:


(Odynplus) #11


public LogConfig(PrintStream defaultPrintStream, boolean prettyPrintingEnabled) {

            this(defaultPrintStream, prettyPrintingEnabled, null, true);
  
  
    
        }

Это?


#12

Если я правильно понимаю, enablePrettyPrinting это вывод не одной строкой, а с форматированием
{
  param: value
}
но вывод все равно в defaultPrintStream т.е на консоль.
Вариант писать в лог только перехватывать вывод на консоль.

Может у кого то есть решения?


(Odynplus) #13

Так ведь этот defaultPrintStream в конструктор сам передаешь. Какой передаш такой и будет. В тестах они например в StringWriter обернутый в PrintStream пишут, т.е. явно не в консоль. Вот еще нагуглил http://stackoverflow.com/questions/14476112/how-to-get-rest-assured-log-into-something-printable-in-a-text-file , там и PrintStream для slf4j готовый


#14

Попробую. Спасибо большое за подсказку


#15

Всем привет :smile:

Возможно кому то пригодится такое решение.

У меня была задача - получить логи Rest Assured запросов и ответов при работе с API, и выводить их в лог отчета.
Я использую Allure для формирования отчета и мне хотелось прикреплять файлы с логами по ходу выполнения шагов.

Спасибо @odynplus подсказал где посмотреть. Нашел вот целый архив примеров

Для решения моей задачи можно испоьзовать фильтры
filters(new ResponseLoggingFilter(responseVar), new RequestLoggingFilter(requestVar)).

Итого у меня получилось

final StringWriter writerReqest= new StringWriter(); final StringWriter writerResponse = new StringWriter(); final PrintStream requestVar = new PrintStream(new WriterOutputStream(writerReqest), true); final PrintStream responseVar = new PrintStream(new WriterOutputStream(writerResponse), true); given(). filters(new ResponseLoggingFilter(responseVar), new RequestLoggingFilter(requestVar)). body("somebody"). when(). post("https://httpbin.org/post");


(Eugene Moskalenko) #16

Тоже столкнулся с задачей, писать автотесты для REST API, смотрю в сторону rest-assured. Вы случайно еще свою реализацию не выкидывали куданить? Поглядеть, может и не стоит такого монстра использовать :slight_smile:


(Andriy Yarish) #17

Rest assured - зручно використуватти як НТТР клієнт, за допомогою нього можна формувати реквести-виконувати, діставати респонс а далі із респонса все що нам потрібно і робити перевірки за допомогою наприклад TestNg . 1. Пишем ДТО класи для серіалізації/десеріалізаці реквестів/респонсів 2. Формуємо Мапу з пас/квері параметрами із обєкта відповідного класу або джсон (1респонс 1 реквест для одного сервісу) 3. Створюємо RequestSpecBuilder requestSpecProt = … один раз з переаналізацією перед кожним тестом із загальними параметрами (урл, пас, хедери …)4. В кожному тесті доповнюємо білдер всім необхідним 5. Response resp = given(requestSpecProt.build).log().all().get() 6. В фреймворку є можливість дуже простим способов валідації Джсонів через Джсон схем


(Taras) #18

а нашо DTO - ошки , якшо замобами фреймворку валідувати json ?)


(Andriy Yarish) #19

. Джйсон схеми дозволяють валідувати назви параметрів, перелік параметрів. формат, загальні патерни по значеннях … ДТО виступають допоміжними обєктами використовую у випадках коли потрібно діставати конкретні значення чи колекції значень із Джсонів .


(Cosmic Orange) #20

Спасибо @odynplus подсказал где посмотреть. Нашел вот целый архив примеров

Линк побился после перетрубаций с названиями. В общем вот свежий линк на примеры, если вдруг кому нужно будет.