Народ, выручайте! Надо срочно начать разрабатывать #framework для тестирования #soap веб сервисов.
Нужно включаться быстро в работу и не падать фейсом в грязь.
Обязательно писать буду на #java . Сам проект Спринг бут + что-то там еще.
У меня есть всдл-лина с 40 методами. Вручную у меня есть понимание как я хочу тестировать (#soapui ).
Как я это вижу по степам:
Популирую базу тестовым комплектом данных (делаю проверку на иф эксист)
Формирую реквест как мне надо
Получаю респонс, провожу ассерты
Удаляю тестовые данные.
Подскажите как начать? Если я правильно понимаю - я вскармливаю всдл-лину какой-то либе и она генерит мне джава классы, потом я пишу с объектами логику, а либы генерят туда-сюда это все в хмл и пуляют его на сервер, сервер отвечает, либы анмаршалят это снова мне в объекты и я работаю с ними (ассерты).
Посоветуйте либы пожалуйста, может где-то можно глянуть на хелловорды того чего я хочу.
Напишити как правильно это делать. Может я пошел не в ту степь.
А чем #soapui не устраивает? Тут вам и прекондишены в БД можно залить и с ассертами париться не нужно.
P.S.: если стандартных ассертов не хватит можно подключить XMLUnit
А какая причина в обязательности писать на Джава?
Я как-то юзал JAX-WS для тестирования SOAP сервисов, может я тогда был еще зеленее чем сейчас, но было много “сгенерированных классов” и прочей лабуды с которой было много возни.
Мне кажется, что SOAP UI классная штука для подобных задач.
+1 к идее писать на SoapUI, если надо включиться быстро. Более того, хочу добавить, что SoapUI позволяет генерить отчёт при запуске через командную строку, таким образом, интеграция с CI тулами возможна.
Гайс, фёст оф олл я хочу поблагодарить за ваши 7 ответов. Все они мне очень помогли.
Теперь к сути:
Айтем первый - я согласен #soapui одно из самых подходящих и ГРАЦИОЗНЫХ решений. И я его конечно буду использовать. Но…
Что вы все как не первый год в индустрии? Дано жирный клиент, которому это стоит достаточно денег.
Он должен быть сатисфаед что за свои потраченные деньги он получил код на джаве, который писали аутомейшины, а не девочка, которая 2 недели назад прочитала туториал по фришной тулзе. Плюс ваш покорный слуга прокачает новый скилл и его стоимость вырастет на пару копеек.
Да-да, не удивляйтесь, это так. Вы здесь под реальными именами и сейчас в меня наверное полетят тапки, но я ТОЧНО знаю читая это вы улыбаетесь и понимаете о чем я
Айтем два: спасибо что вставили картиночку с кружочками к моей мессаге, теперь стало красивше.
Теперь, ребята, если вы не против я поуточняю ваши ответы. Сделаю все в одном сообщении:
@dimand58 - загуглил WSLite - вроде крутая штука, но там груви, значит надо будет дополнительно разбираться. RestAssured разве подойдет для соап?
@rmerkushin спасибо за ссылку на XMLUnit. На выходных разберусь с чем его едят.
@ysparrow, я рад что вы оценили мой слог, но разве эти простые слова далеки от сути?
@Viktor_Borisov по поводу желания использовать джаву - ответил выше
Defender насчет спарить с дженкинсом, мне понравилось, буду гуглить. Возможно подскажите годный матеал по этой теме?
@Sergey_Pirogov с груви у меня нет опыта, может вас не затруднить написать более развернутый ответ под мою задачу. Как это архитектурно выглядеть должно?
И еще, ребя, а можно как-нибуть изголиться и получить профит от использования для тестирования CXF? Гляньте какую вкусную ссыль я нашел
При желании можно развести заказчика на про версию #soapui, а так же заюзать #groovy + XMLUnit и еще любые #java либы на ваш вкус Можете даже написать что-то свое на #java если очень хочется именно ее )
Что именно использовать, это скорее дело вкуса, будь то jax-ws, cfx, или axis. Попробуйте и выберите то, что больше подойдет вашему проекту. А лучше попросите помощи разработчиков.
Ваша ситуация чутка странная, а позиция “клиент просит сделать дорого, поэтому буду делать дорого” бросает тень на всю отрасль и тестирования и автоматизации и заказных работ (аутсорса).
Я с таким сталкивался и не сторонник подобного.
По поводу Soap, то тут вам нужно иметь ввиду еще нюансы проекта. Там под одной вывеской есть несколько форматов и не всегда из WSDL получаются нормальные классы, а также есть минимум пара различных способов приема/отправки и не факт, что у вас тот, что применяется в распространенных в интернете ответах.
У нас, например, был как раз такой случай. Когда запрос soap внутри содержал одно поле, внутри которого была настроящая XML, кодированная в base64.
В принципе против Java я ничего не имею и вполне возможно, что ваш клиент имеет какие-то свои непонятные резоны просить работать именно с ней, например, у нас вполне себе она используется на проекте. В том числе и для soap-сервисов и там не было никаких особых сложностей, а по скорости разработки сопоставимо с работой в SoapUI, может чуть медленнее и не так наглядно, зато проще в поддержке и меньше копипасты.