Notice: Undefined index: height in /var/www/ on line 27
Tutorial: Flow SoapUI Plugin –

Tutorial: Flow SoapUI Plugin

What’s this?

This is a plugin i decided to write this week for SoapUI and consequently Ready API, both SmartBear products. Both has a very nice plugin architecture these days, very eloquently describe by Ole himself here, the original SoapUI developer.

Personally i’m quite familiar with the codebase, having worked at SmartBear for a time a few years ago, but i’ve never really had the time or idea to put the effort of trying it out before. So, at my newest assignment there’s a few SOAP services that have a the characteristic that they are REALLY unstable. Every second request fails at some point in it making the test-cases fail intermittently in SoapUI. We’re in the process of automating a number of testcases using the soapui-maven-plugin. So, what the team has done is to wrap the teststeps that are really unstable with groovy-scripts and conditional gotos to make it reset and do the test-step again. Essentially we ended up with three teststeps just to run one unstable step. I know what you are thinking. Why in the world would you want to have a teststep failing every other time? And i agree with you. If i was in change i would dig into what is making it fail and fix it. The problem here is that the service is dependent on a third-party service that we don’t have control over and that the owner is too scared to replace or modify, and we really need the data from that service. But we can’t have four times as many test-steps just because of this problem, either, that’ll get hard to maintain for us. So let’s write a plugin that repeats a number of steps if they have failed for a few attempts!. And here it is!


First follow the guidelines on GitHub that explains where to put files and how to jailbreak the plugin if you need that then [here’s] a guide on how to use the plugin. But to keep


Okay, so the plugin is installed and you are ready for testing, now what. SoapUI should have picked up the plugin automatically and you can find it in your list of test-steps.

Just add the test-step and make sure to point out which test-step you want to iterate from.

If all assertions and test-steps are successfull then the test-step simply succeeds and continues to the next one. If not then it will begin another iteration until it have iterated as many times as are specified in the max attempts dropdown.

When the repeat-test-step is configured you can give it a go by running the test-case. Here i use the sample-project which is provided with the plugin source-code. It’s very simple, it is testing by sending GET-requests to a mock-service i set up with two resource-urls. /everyThirdTime and /everyTime. It’s fairly obvious how often they return a 200 OK HTTP response right? Great. The mockservice is started and stopped in the setupScript and teardownScript of the testcase.

So the SoapUI test-case consists of three test-steps, works_every_time, works_every_third_time and Repeat Test Step which is configured to repeat two times. So the unstable test-step is the second one, and let’s remember that i configured the mockservice to respond 200 OK to the third request. So two attempts should be enough to make the service pass. Which it does, very reproducible. So much so that i included it as a regression-test for the plugin in TravisCI.

The test-runner will show the historic failed results in the log but will be a successful test-case as long as at least one iteration is successful. If it successful at the first iteration then the repeat-test-step will not trigger any iterations at all.

Plugin Development

I won’t go into detail about the development itself, that’s a topic for another post, which i might write someday. It was a very nice experience to be honest, the plugin architecture of SoapUI lately is very formidable and wraps things like xmlbeans configuration nicely by parsing annotations instead so we don’t have to think about it as plugin-developers. But i more or less followed Oles tutorial on that part until i had the test-step reachable inside of SoapUI. From there it was just a matter of manipulating the components of the TestStep Plugin run-method and utilizing the API which already had support for manipulating the control-flow around the test-steps. The tricky part was to get it to un-fail the test-case after it had failed test-steps of a previous iteration after following iteration had passed. I solved that by removing the test-results of the previous iterations test-steps and upon success of an iteration i manipulate the testCaseRuncontext property, see below.

if (allRelevantTestsPassed) { 
   testCaseRunContext.setProperty(TestCaseRunner.Status.class.getName(), TestCaseRunner.Status.RUNNING);

This was actually quite hidden as there are no method on the testCaseRunContext to set the status of the testrun, but since SoapUI is fairly open source i could just checkout the source and have a look at how it handled it internally so i could do it myself. As i discovered the status is a property.

That’s it! I hope you’ll find the plugin useful. Do give me a shoutout if you find any bugs or have any feature requests for other test-steps or SoapUI components go to GitHub and report them as issues on the github project.

No Comments

You can leave the first : )

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.