Scripting and the Script Library

User rating:
1.8 (205 ratings)

NOTE: This page contains information for SoapUI Pro that has been replaced with Ready! API.
To try enhanced scripting functionality, feel free to download a SoapUI NG Pro trial from our website.

SoapUI provides extensive options for scripting, using either Groovy or Javascript (since SoapUI 3.0) as its scripting language, which to use is set a the project level in the project details tab at the bottom left. The majority of the documentation available here will be for the Groovy language, as it greatly simplifies the scripting of Java APIs (you can get more information, tutorials, etc on the Groovy Web Site). An overview of how to use JavaScript instead is further down in this document.

Scripts can be used at the following places in SoapUI:

  • As part of a TestCase with the Groovy Script TestStep, allowing your tests to perform virtually any desired functionality
  • Before and after running a TestCase or TestSuite for initializing and cleaning up before or after running your tests.
  • When starting/stopping a MockService to initializing or cleaning-up MockService state
  • When opening/closing a Project, for initializing or cleaning-up Project related settings
  • As a dynamic DataSource or DataSink with the corresponding DataSource/DataSink test steps
  • For providing dynamic MockOperation dispatching.
  • For creating dynamic MockResponse content
  • For creating arbitrary assertions with the Script Assertion
  • To extend SoapUI itself (see Extending SoapUI), for adding arbitrary functionality to the SoapUI core

All scripts have access to a number of situation-specific variables, always including a log object for logging to the Groovy Log and a context object for perform context-specific PropertyExpansions or property handling if applicable. A context-specific variable is always available for directly accessing the SoapUI object model.

1. Script Editors

Script editors are generally available as inspectors at the bottom of the corresponding objects editor, each having a run button, a drop-down edit menu (same as the right-click popup), an information label, and a help button;


The popup-menu (as shown above) contains standard edit-related actions and will in SoapUI Pro contain a "Get Data" menu option that expands to show all properties available within the current scope. Selecting a property (or the option to create a new one) will eventually create a script to get the variable, for example

def test = context.expand( '${#Project#test}' )

Which gets the Project-level "test" property.

It is also possible to drag a property from the navigator tree when it is in Property Mode into the script; if the dragged property is "within scope" (i.e. can be accessed via property expansion), the corresponding access script will be created at the caret location

2. Groovy Script Library

SoapUI Pro adds the possibility to have a central library of Groovy Classes that can be accessed from any script within SoapUI, which can be useful for centralizing common tasks and functionality and for creating SoapUI extensions. Use as follows;

  • Specify which folder to use in the SoapUI Pro Preferences tab (default is /scripts). SoapUI Pro will check this folder for files with the "Groovy" extension and compile these upon startup. The folder is then checked periodically (every 5 seconds) for updates and new or existing scripts are compiled and re-compiled if necessary.
  • Scripts should be placed in folders named after their containing package, ie a script in the package soapui.demo should be in a soapui/demo folder under the specified scripts folder.
  • The compiled classes are added to the parent class loader of all Groovy scripts, you can access them as standard java classes.

Remember that the script files must be valid classes, not just arbitrary scripts. So as an example, lets setup one of these Groovy objects. First, create a directory (e.g. "C:\GroovyLib"). Then add a "Callee.groovy" file in that folder with the following content:

package soapui.demo

class Callee {
  String hello() {
     return "Hello world! "
  String hello(String who) {
     return "Hello $who! "
  def static salute( who, log ) { "Hello again $who!" }

Now let's setup SoapUI Pro to load up your Groovy library. Set File > Preferences > SoapUI Pro tab > Script Library. So I would set that to "C:\GroovyLib" in my example.

Note: Restart SoapUI Pro to pick up the new library script.

Now if we create a Groovy Script Step in a TestCase, we can use the above class with the following:

c = new Callee() c.hello("Mike")

Running this from within the Groovy Editor will show the following in the Groovy Editors log:

Tue Dec 31 10:49:05 EST 2013:INFO:hello, Mike

We can also call the static salute method:

soapui.demo.Callee.salute( "Mike", log )

Which will produce the following output:

Tue Dec 31 10:51:47 EST 2013:INFO:Hello again Mike!

If we now modify the above Callee.groovy file and change the first salute method to include an exclamation mark at the end, SoapUI Pro will pick up the modified file (once it has been saved), which is seen in the SoapUI Pro log:

Tue Dec 31 10:54:44 EST 2013:INFO:C:\GroovyLib\Callee.groovy is new or has changed, reloading...

And now when we rerun our initial script we get;

Tue Dec 31 10:56:08 EST 2013:INFO:hello, Mike!

3. Code Templates

SoapUI Pro 2.5 adds rudimentary support for configurable code templates which will be activated when typing the correspondig template ID and pressing Ctrl-Space in an editor. Templates can be added/changed in the Preferences\Code Templates page, the following templates are available by default:

  • grut - def groovyUtils = new context )\n|
  • xhre - def holder = groovyUtils.getXmlHolder( "|#Response" )

The '|' designates the position of the caret after inserting the template.

4. JavaScript support

SoapUI 3.0 adds support for JavaScript as an alternative scripting language. When configured, all scripts in the containing project will be interpreted using a JavaScript engine (Rhino) instead (read more about the Rhino engine and supported features at ... ). For those of you used to JavaScript this might be an easier language to get started with.


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 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.