soapUI Tutorial

JRA1 Meeting
Cambridge 8 June 2007
Michalis Michael
Cynet
What is soapUI?
 soapUI is a free and open source desktop
application for inspecting, invoking,
developing, simulating/mocking and
functional/load/compliance testing of web
services over HTTP.

 More on soapUI on http://www.soapui.org .

Getting Started I
 Download whatever version of soapUI you
wish from http://www.soapui.org according to
your system (Linux-Windows)

 Install it according to the instructions on your

system.
Getting Started II
 In order to begin testing a service we need to have a
WSDL file describing it . Unfortunately our services
current WSDL files are very generic and soapUI can’t use
them.

 You can start learning how to write WSDL files at

http://www.w3schools.com/wsdl. Or you can just use an
all ready existing WSDL file as template and modify it as
you please .
 We need to create two separate WSDL files. One for the
service request and the other for the service response.
This is due to the fact that the request and response
schema use the same root element.
Getting Started III
 Next you will need to create the .xsd files needed in the WSDL
description so that soapUI can validate the schema our
services responses.

 Our services schema is described in a Relax NG syntax. Relax

NG syntax can be turned into xsd with he help of trang
$mkdir service-req service-res
$trang service-req.rnc service-req/service-req.xsd
$trang service-res.rnc service-res/service-res.xsd

Note that the xsd files are created in a directory because more
than one xsd files may be created each time.

You can find trang here:

http://www.thaiopensource.com/relaxng/trang.html
Getting Started IV
 Unfortunately its very common for the xsd files
created by trang not to be accepted as a valid
schema by soapUI.
 This is because our rnc files may contain
multiple definitions for the same elements as
nmwg:data or nmwg:metadata. To bypass this
the services rnc files have to be modified
accordingly.
 However this may loosen the schema or if the
modification is not the appropriate one, change
it.
Creating Tests I
 Click to start soapUI
 Now lets create a WSDL project. Go to the
menu bar and click File -> New WSDL project
 From there you can give the project a name.
Because of path problems its not recommended
to add a WSDL file yet. Click ok and the project
will be created
Creating Tests II
 Right click on the newly
created Project and choose
Add WSDL from URL.
 Then enter something like
file:./request.wdsl
 In windows this may not
work. If this is the case
then choose Add WSDL
from file.
 Then agree to Create
default Requests for all
operations.
 Then you will see that a
request was created based
on your WSDL description
Creating Tests III
 The example requests
accuracy is determined
by the detail of the
definitions in the xsd
files
 You will notice that it’s
not quite like the real
thing and modifications
are required. You may
modify it or you can
simple copy paste an
example request inside
the <soap:body> tag.
Creating Tests IV
 Right click on the service
interface icon and choose
Generate Testsuite in
order to create the
container for the test
cases to come
 This will create the
container for the test
cases to be defined.
Creating Tests V
 To create a new test
case right click on the
newly created Testsuite
icon and choose New
TestCase. Give it a name
and the new test case is
created.
Creating tests VI
 To add a request to
the test case right
click on the example
request and choose
Add to Testcase
 The test suite and
test cases can be
manipulated by right
clicking on their
icons and selecting
their corresponding
editors.
Creating tests VII
 The request window should
now appear. Click on the
green play button on the
upper left side to send the
request to the service.
 You can set the service
address in the text bar on
the top of the window. The
response will appear on the
right hand side
 By right clicking the space
below the window you can
add assertions-tests for the
response
Creating Tests VIII
 Choose schema
validation and in the
next message box
choose the response
WSDL file
 soapUI will then validate
the response.
 In the same manner one
can add soap fault
assertions XPath
matches or simple
contains matches
Creating Tests IX
 XPath matches are one of
the most useful features of
soapUI
 Choose the XPath matches.
Then click on declare. Add
your XPath expression and
click Select from current.
The result of the XPath
expression on the response
will appear on the expected
result box
 If it is what you were going
for click save and there you
are!
Creating Tests X
 In the same manner one
can add tests for the
response not being a
soap fault or just to
check if a certain string
is part of the result
 For more in depth testing
and for database access
the use of a Groovy
script is needed…
Getting Started with Groovy
From the Groovy home web page:
Groovy ...
 is an agile and dynamic language for the Java Virtual Machine
 builds upon the strengths of Java but has additional power features
inspired by languages like Python, Ruby and Smalltalk
 makes modern programming features available to Java developers with
almost-zero learning curve
 supports Domain Specific Languages and other compact syntax so your
code becomes easy to read and maintain
 makes writing shell and build scripts easy with its powerful processing
primitives, OO abilities and an Ant DSL
 increases developer productivity by reducing scaffolding code when
developing web, GUI, database or console applications
 simplifies testing by supporting unit testing and mocking out-of-the-box
 seamlessly integrates with all existing Java objects and libraries
 compiles straight to Java bytecode so you can use it anywhere you can use
Java
Groovy I
 Our goal is not to give a complete tutorial on groovy but
to give the necessary groovy tools needed for functional
testing. After all tutorials on groovy are available on the
groovy and soapUI web pages
 Groovy is a powerful scripting language with a syntax
very similar to Java. The major deference is that there is
not exact declaration of the type of each variable but
just a generic def declaration or with no declaration at
all.
 For a beginners tutorial look at
http://groovy.codehaus.org/Getting+Started+
Guide
.
Groovy II
def knownResultsMap=[id:"DFN-Surfnet-Link-5678",status:"down",admin:"UNKNOWN"]
def sql = Sql.newInstance("jdbc:mysql://192.168.10.86:3306/perfsonar_ma", "perfsonar_ma",
"testpass", "com.mysql.jdbc.Driver")

def resultList=[]
sql.eachRow("select id,status_oper,status_admin from domain_link"){
def result=[:]
result=[id:it.id,status:it.status_oper,admin:it.status_admin]
resultList.add(result)
}
Above you can see an example of accessing a mySQL database and
retrieving data from it.
First we define a map
def knownResultsMap=[id:"DFN-Surfnet-Link-5678",status:"down",admin:"UNKNOWN"]

This map contains what we expect from the database

Note: All examples to work need the proper imports!

Groovy III
def sql = Sql.newInstance("jdbc:mysql://192.168.10.86:3306/perfsonar_ma",
"perfsonar_ma", "testpass", "com.mysql.jdbc.Driver")

 Then a connection to the mySQL database is established,

providing the address the username the password and the
driver.
def resultList=[]
sql.eachRow("select id,status_oper,status_admin fromdomain_link"){
def result=[:]
result=[id:it.id,status:it.status_oper,admin:it.status_admin] resultList.add(result)}

 With sql.eachRow the select statement is executed and the results are stored
inside the result map with the help of an iterator “it” . The result map holds the
results for one row and all rows are stored in the result list.
 There is not need to declare the iterator, its “built-in” with the .eachRow method
Groovy IV
resultList.each{
if((it.id==knownResultsMap.id)&&(it.status==knownResultsMap.status)&&(it.
admin==knownResultsMap.admin))
println "\n We have a match" + "\n"+ it.id +" "+it.status+" "+it.admin
}

 Next the results from the query and the

expected results are cross checked
 Notice that with the “.each” method there is no
need for “for” or “while” loops or “iterators”.
Groovy V
 There is no native Groovy support for the eXist
database though…
 But no problem there, groovy can still use java
libraries instead here is an example:
Class cl = Class.forName("org.exist.xmldb.DatabaseImpl");
Database database = (Database) cl.newInstance();
DatabaseManager.registerDatabase(database);
Collection collection =
DatabaseManager.getCollection("xmldb:exist://192.168.10.86:8080/exist/xmlrpc/db/sqlmaco
nfig", "sqlmaservice", "testpass");

 The traditional java method and classes can be

used for accessing eXist, lucking of course
groovy’s capabilities.
Groovy and soapUI I
 Groovy is an essential part of soapUI
 However looking at soapUI’s getting started guide one
can conclude that groovy scripting was not incorporated
into soapUI for the reasons we want to use it
 Groovy is used in soapUI primarily as a control step,
getting results from other steps and passing them to
other steps. It can even be used to create new test
steps, restart old ones or decide which steps to start
based on the results of the old ones.
 Nevertheless groovy’s capabilities as a scripting
language counter the native soapUI problem and allow
us to bypass this disadvantage
Groovy and soapUI II
 Groovy can access test steps through the testRunner
instance.
def request = testRunner.testCase.getTestStepByName( "MetadataKeyRequest1" );
def property = request.getProperty( "Response" );
println property.value
 In the previous example we’ve accessed the
MetadatakeyRequest1 object through the testRunner
instance, then through testCase and finally got what we
wanted from the getTestStepByName method
 Next we obtained the response through the request
object using its getProperty method.
 The Groovy-soapUI combination has some powerful xml
handling capabilities which we intend to use…
Groovy and soapUI III
def response = new groovy.util.XmlParser(false,false).parseText(property.value);
def parameters=response["soapenv:Body"] ["nmwg:message"] ["nmwg:data"]
["nmwg:key"]["nmwg:parameters"]["nmwg:parameter"]
parameters.each{
println it['@name']
println it.text()
}

 From the above example we can see the power of

groovy on xml
 We got the response document through the
groovy.util.XmlParser and then accessed the parameters
element through a very simple XPath API
 Then with the help of the .each method and the XPath
API we’ve accessed all the parameter element
Groovy and soapUI IV
 As said before the groovy scripting step was not intended to be
a testing mechanism but rather a control unit.
 So there is no way I could find that could allow a groovy script
step to fail as a test request step.
 But there are ways to get around that
log.info "script failed“
log. error "script failed“
 Through the log instance you can report any failures to the
logging space at the bottom of the groovy script window
 The logs output is the soapUI log
 Or you can just throw an exception
throw new Exception( “script failed" )
Groovy and soapUI V
 But the best way in my opinion is to write the result of the
groovy script to an external file along with the results of all
tests

def fields = ["a":"1", "b":"2", "c":"3"]

new File("foo.ini").withWriter { out -> fields.each() { key, value -> out.writeLine("$
{key}=${value}") }
}

 The former piece of code uses the withWriter method and the
help of a “closure” to write the map to the file.
 Writing our results with the help of groovy to an external file,
can give us the reporting capability that we have using
traditional languages for functional testing as Java and Perl
Groovy and soapUI VI-Tips
 The groovy script editor is pretty raw and I
wouldn’t suggest it for any serious developing
 I’d suggest to install groovy on a machine and
try most of the code apart from soapUI
 There is also an eclipse plug-in. Instructions on
how to install it are found at
http://groovy.codehaus.org/Eclipse+Plugin
 When you finish testing the code pieces that
are independent from soapUI you can copy the
code to the soapUI script editor and add the
remaining code.
Groovy and soapUI VII-Tips
 Be careful! The embedded groovy language in soapUI
can only accept new packages only if it is installed on
your machine. JNLP versions can not accept new
packages.
 Adding new packages to the embedded groovy-such as
xmldb- can be tricky.
 Modification of soapUI.bat or .sh is needed.
 Copy the packages you want to add in the lib directory
of the soapUI installation folder.
 Then modify the soapUI.bat or .sh file adding
set CLASSPATH=%CLASSPATH%;..\lib\mypackage.jar
 Restart soapUI so that the changes may take place
 This is necessary for the mysql-connector and xmldb
packages.
Groovy and soapUI VIII
Questions?
Thanks!

A special thanks to Jochen Reinward for his

precious assistance on soapUI and on the rnc
to xsd transformation. This tutorial was heavily
based on Jochen’s instructions found on svn.

Thank you all for watching!