Skip to content
Cart

The SoapUI Object Model

We are seeing more and more users doing rather advanced scripting in their SoapUI projects, for example

  • controller scripts that run TestCases, LoadTests, etc
  • dynamically generating testrequests and assertions based on database content
  • creating custom reports after execution of tests
  • integrating with external tools (test management, etc)
  • creating complex simulations of asynchronous services using Mocks and TestCases

Since groovy scripts in soapUI have full access to the soapUI object model, anything is possible. Unfortunately though the API documentation is only available in javadoc format and can be hard for new users to grasp, especially if they lack prior knowledge of java or groovy. I’ll walk you through the basics of the soapUI API, hopefully giving you a foundation for further exploration.

Scripting in SoapUI

soapUI has extensive support for spicing up your projects with scripts written in the groovy language.

As you can see, the possibilities for customizing the behavior of your soapUI testing projects are quite extensive.

A note on the choice of groovy, when we started to provide scripting possibilities in 2006, groovy was the natural language of choice. Now this has changed and there are many viable alternatives to groovy via th Java 1.6 scripting API (JRuby, Jython, Javascript, etc), but since we have made our own optimizations for the Groovy ClassLoaders which would not be available for these other languages, we have opted to stick to groovy instead of providing “sub-optimal” support for other languages.

All things are ModelItems (almost)

In soapUI all project-related artifacts (Projects, Requests, TestSuites, etc) are ModelItems, their interfaces are all defined in the com.eviware.soapui.model package and sub-packages (for example have a look at the com.eviware.soapui.model.iface package for Interface/Operation/Request related classes).

A modelItems’ name, description, icon, etc. can all be accessed through the corresponding getters, for example

log.info project.name

would print the name of the project variable.

Obviously depending on which type of ModelItem, properties and methods for accessing children are available. The general model for accessing children of a certain type to a ModelItem is as follows (XX = the type of child):

int getXXCount() XX getXXByName( String name ) XX getXXAt( int index ) List getXXList() Map getXXs()

For example to get a certain MockService in a project you could use one of

def mockService = project.getMockServiceByName( “My MockService” ) def mockService = project.getMockServiceAt( 0 )

for iterating all LoadTests in a TestCase you could

for( loadTest in testCase.loadTestList ) log.info loadTest.name

Since groovy simplifies map access the last can be used in several ways from a script, for example if we have a TestSuite and want to access its TestCases we can do both

testSuites.testCases[”…”]

and

testSuites.testCases.”…”

Parent objects are generally available through the name of their type, ie

log.info( testCase.testSuite.name + ” in project ” + testCase.testSuite.project.name )

Navigates “upward” in the object model using the testSuite and project properties.

Properties

You will often want to manipulate properties within your scripts, either those that are built on or those that are custom properties, the later can be set on the following objects in soapUI, Projects, TestSuites, TestCases, MockServices and the PropertiesTestStep (these all inherit from MutableTestPropertyHolder).

Setting/getting properties is straightforward

// set property value object.setPropertyValue( “name”, “value” ) object.properties[“name”].value = “value”

// get property value log.info object.getPropertValue( “name” ) log.info object.properties[“name”].value log.info object.properties.”name”.value

Contexts

When scripting inside some kind of “run”, there is always a context variable available for getting/setting context-specific variables. The contexts are:

  • SubmitContext - available within one submit of a request
  • TestRunContext - available from within all scripts in a TestCase run
  • LoadTestRunContext - available in LoadTest setup/tearDown scripts and from the exectued TestCase context via the LoadTestContext context variable
  • MockRunContext - available in MockService startup/shutdown scripts and MockOperation/MockResponse dispatch scripts

All these inherit from the PropertyExpansionContext interface which has methods for setting/getting properties and an expand method which can be used to expand arbitrary strings containing Property-Expansions, read more on this in the soapUI User-Guide.

Logging

As you’ve noticed, there is a “log” variable in all scipts. This is a standard log4j Logger which appends to the groovy log tab at the bottom of the soapUI window and can be used for diagnostic purposes, etc.