All about SOAP UI and Groovy in it

Our business will continue as usual, only better;

via eviware becomes SmartBears | Eviware Blog.

Looping in Groovy Step

While testing several conditions or performing the same operations over a range of values, we intend to use loops. We have three ways to accomplish looping in a groovy step.

1)      while

2)      for

3)      closures

For developers ‘while’ and ‘for’ are familiar operations.

while

Usage:  while (condition) {

// useful code here, which keeps executing until the condition is true

}

Example:

def a = 3;

while (a > 0) {

a- -;

log.info(‘ more ‘ + a + ‘ loop(s) left’);

}

for

Usage: for (x in <some range of values>) {

// useful code here, which executes till the iteration over range of values is complete

}

Example:

for ( ad in 0..9) {

log.info(ad + ‘ inside’);

}

For more usages of ‘for’ loop click here.

closures

closures are similar to iterators. We mention an array or map of values, and write a closure to iterate over it.

To access the current value in the loop ‘it’ is to be used (but not ${it})

Usage/Example:

def  sampleArray = [“dev”, “integration”, “qa”, “prod”];

def a = 1;

sampleArray.each() {

log.info(a + ‘:’ + it);

a++;

}

If you have a map to iterate in groovy step like below

def sampleMap = [ "Su" : "Sunday", "Mo" : "Monday", "Tu" : "Tuesday",

"We" : "Wednesday", "Th" : "Thursday", "Fr" : "Friday",

"Sa" : "Saturday" ];

then use

stringMap.each() {

log.info(it);

log.info( it.key + ‘:’ + it.value );

}

Note: break and continue statements can be used only in for and while loops but not in a closures.

So if you wish to conditionally come out of the loop, its better you use for or while.

(break – as and when encountered comes out of the loop completely;

continue – as and when encountered, skips all the succeeding steps in the loop and starts with next iteration. )

(Please feel free to get back if u have any trouble…as i’m just a mail away…otherwise leave a comment)

Script assertion in SOAP UI helps the developer to immediately run some primary tests after the current messageExchange.

It feels/sounds similar to Groovy Script test step but, in a lot ways it’s more handy. If say we want to validate on the response time and proceed further for succeeding test steps, it feels heavy to have a Groovy step to do that; instead, the Script Assertion implicitly does that job (can be done using “assert messageExchange.timeTaken < 1000”). Using this we could make the Test Suite look more credible and modular.

Script Assertion has access to messageExchange, context and log objects.

We can access the request and response xml as below -

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )

def requsetHolder = groovyUtils.getXmlHolder( messageExchange.requestContent )

def responseHolder = groovyUtils.getXmlHolder( messageExchange.responseContent )

using the above holders we can get hold of the all elements in response and request xml of the latest messageExchange.

While accessing the elements of request/response xml, using the corresponding namespace(s) for every element is very important. If the response xml is simple (that is, mostly all the elements are referenced by one namespace), then xpath would be simple to trace. But if various elements are referenced by various namespaces, then we should be cautious while framing the xpath.

Here are my observations regarding this:

Lets say following is the response xml obtained after running the Test Request step(which has the script assertion)

Sample Response xml

Sample Response xml - I

In the Script Assertion step, to access RefNum field (of the above response xml), we write

def refNum = responseHolder.getNodeValue(“//trans:ProcessMessageResponse/content/Response/RefNum”)

And say if the response xml has various namespaces to refer its elements as below

Sample Response xml - II

then to access the same RefNum value, the xpath used should be

def refNum = responseHolder.getNodeValue(“//trans:ProcessMessageResponse/ns1:content/ns2:Response/ns2:RefNum”)

or

def refNum = responseHolder.getNodeValue(“//ns2:Response/ns2:RefNum”)

This might raise some ambiguity regarding ‘ns2‘ namespace ref. which I have used to access the RefNum value, though it is nowhere present in the response xml.

What I figured out is default namespaces are named as ns1, ns2 and so on (as applicable) in the order of their occurrences. In the above xml, ‘content‘ element is referred with ‘ns1’; and ‘Response‘ element is referred with ‘ns2’. And thus the xpath is so.

We can verify which namespace is given which name, by clicking the ‘Declare’ button in XPath Assertion window (though this can be done to know the names of different namespaces present in response xml only). But to know, the names of different namespaces present in request xml, ordering logic (what i have mentioned above) should be employed.

Not only while applying Script Assertion, the above explanation (that is, building precise xpath with appropriate namespace references) applies to all the situations where developer needs to access any element of request/response xmls.

Tag Cloud

Follow

Get every new post delivered to your Inbox.