SoapUI - Updating multiple testcases quickly

[kenm]

Good morning fellow SoapUIers,

One criticism I've seen leveled at SoapUI, and have personally experienced, are the challenges around widespread test updates. For example if a single API call, with assertions on some attributes of the response, which is used in many many testcases is updated then you may have tens of not hundreds of testcases to update.

I tend to find this time consuming in comparison to more traditional IDEs. Are there any fast/efficient ways to address this?

Thanks in advance for your time! morning   🙂

Ken.

[groovyguy]

One quick way to update it, if you know what changes need to be made, is to write a groovy script to parse every test step and its assertions in a project and change the contents of the script assertion. Or to open the XML file itself (if its not a composite project) and do a find/replace all.

Within ReadyAPI itself, depending on the cause that is driving your changes, if you have to update/wsdl/schema you can use the "Refactor" option to potentially update XPATH within all of the assertions.

Can you provide a bit more detail? What is driving your change and what do you need to change on the assertions?

[kenm]

Cheers for the detailed response,

Typically it's response payload structure changing breaking assertions. That specific call may be used in many many places across the entire solution. We use composite projects so global search and replace on non composite XML not really a runner I'm afraid.

[groovyguy]

If I might ask, what is causing the changes to the response payload structure?

[kenm]

Planned sprint work...

The the response payload itself is being changed based upon business needs however we often have many many tests that are consuming that API call and asserting on fields that now may be renamed/removed etc.

[Lucian]

Another thing that may help is to use dynamic assertions instead of fixed assertions. This is possible in XPath as well in JSONPath . So the assertions won't fail each time when something is changed, well at least they won't fail when something is added or removed from the current response.

Cheers!

[Olga_T]

Hi all,

Thank you so much for your assistance, @Lucian and @groovyguy!

@kenm, is the issue solved? Or, are there any additional details on the matter?

We are looking forward to hearing from you,

[kenm]

I'm afraid it's not resovled.

My assertions themselves are quite granular. On specific fields existence and values... however if the root path of that response structure changes then naturally they start to fail. If this payload response (and assertions) are present in a considerable number of testcases then it'd be helpful to have some sort of global search/global search and replace capabilies.

[groovyguy]

Can you provide some examples? We might be able to figure out a way forward if you can provide:

1. Original response prior to changes
2. Assertion that works on said response
3. New response that assertion no longer validates correctly

With those, we'd have more details that should help us. Otherwise, you may want to consider putting your information and needs into a feature request, which you can do here.