Додаємо свою інформацію в read only об'єкт testStepResult в SoapUI

инструменты soapui
, ,
#1

Історія питання - Solved: Re: How to modify testStepResult? - SmartBear Community

SoapUI як відомо генерує красиві звіти в стилі JUnit. Проблема в тому, що якось їх кастомізувати здавалося не можливо, лише генерувати якісь свій окремий звіт в файл, але у нас весь CI заточений на JUnit звіти.

Осяяння прийшло після глибокого вивчення Java Reflections API. Якщо ви не знали, то за допомогою нього навіть в ініціалізованому об’єкті всі private поля можна поміняти. Здається це можна десь блокувати на рівні JVM security, але в SoapUI пройшло на ура.

Отже в SoapUI Events відловлюємо потрібний нам степ і за допомгою бібліотечки Apache Commons робимо з read-only об’єктом testStepResult все, що нам треба, зокрема перезаписуємо поле messages.

import static org.apache.commons.lang3.reflect.FieldUtils.writeDeclaredField;

writeDeclaredField(testStepResult, "messages", ["Hiiiiiiiiiiiii!"], true);
log.info testStepResult.getMessages()[0]

Вивід в логі:

<...> :INFO:Hiiiiiiiiiiiii!
1 лайк
#2

Когда то баловался с SoapUI. Инструмент неплох, но как по мне очень важно уловить грань когда он начинает ограничивать.
В итоге было решение или покупать про версию и дальше жить в мире SoapUI, или переписывать на полноценный Java проект.

1 лайк
#3

Поддержу.
Сам довольно долго использовал и в некоторых аспектах использую SoapUI, но для длительных больших проектов и командной разработки перешел на Java. У бесплатной версии много ограничений, цена платной велика и в сравнении с бесплатной Java + хорошая IDE все равно проигрывает в гибкости, масштабируемости, удобству, расширяемости и многому другому.

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

#4

Я не скажу, що він ідеальний (напр. мені не вистачає нормального autocomplete в groovy), безкоштовною версією не користувався, тому чесно розумію, що там може обмежувати?
Можна підлючати groovy/Java бібліотеки які хочеш, писати яку хочеш логіку в groovy, якщо стандартна не підходить.
Вже готові стандарнті кроки дозволяють на 95% швидко покрити тестування REST сервісів (за SOAP - не знаю, не тестував їх).
Все це нормально загоняється в СІ.
Недолік єдиий - трохи тупієш, бо менше треба програмувати і напружувати голову, але з іншого боку більше з’являється часу на самоосвіту і пости на форумах :wink:

#5

С rest’ом в soapUI почти не работал, так что могу насчет него и заблуждаться, но мне он казался каким-то костылем прилепленным на скотч, впрочем, мне и jms таким казался. Было стойкое ощущение, что на отличный soap-тул натянули несвойственные ему вещи оставив многие фишки из soap без переосмысления. Вообще, для rest’а довольно богатый выбор утилит и библиотек. Почему не стали использовать, например, postman?

#6

Возможно я что-то не понимаю, но postman - для ручного тестирования, мне надо автоматизацию.

#7

Я его в этом ключе не использовал, но статьи типа “How to write automated test with Postman” видел. Но сам не пробовал и на CI и в DevOps не видел, на том же сайте getpostman есть еще статья про интеграцию с jenkins - “Integrating automated API tests with Jenkins”. Ссылки прямые с телефона неудобно кидать. Попробуйте загуглить.