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.
- Groovy Script TestSteps can be used to add arbitrary functionality to a functional TestCase
- Script Assertions for arbitrary assertion of a SOAP or REST response
- Setup/TearDown Scripts can be used for initialization/cleanup in TestCases, TestSuites and LoadTests
- Startup/Shutdown Scripts can be used for initialization/cleanup in a MockService
- Before/After-Request Scripts can be used for advance dispatching/handling of requests to a MockService
- MockOperation Dispatch Scripts are used to select the corresponding MockResponse for a request
- MockResponse Scripts are used to perform arbitrary functionality for a specific MockResponse
- AfterLoad/BeforeSave Scripts can be used to initialize/cleanup Projects during their lifecycle
- soapUI Extensions can in soapUI Pro be scripted in groovy for extending core soapUI functionality
- the Groovy Script Library is available in soapUI Pro for centralizing common scripts
- Script Property-Expansion is available for performing arbitrary functionality during property-expansion
- DataSource Scripts can in soapUI Pro be used to generated data for TestCases
- DataSink Scripts can in soapUI Pro be used to save data during the run of a TestCase
- DataGen Script Properties can in soapUI Pro be used to dynamically generate Property Values
As you can see, the possibilities for customizing the behavior of your soapUI testing projects are quite extensive.
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
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):
XX getXXByName( String name )
XX getXXAt( int index )
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 )
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
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.
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" )
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.
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.