The ReadyAPI Object Model

Applies to ReadyAPI 3.5, last modified on December 29, 2020

More and more users are now focused on advanced scripting in their ReadyAPI projects, for example:

  • creating controller scripts that run TestCases, LoadTests, and so on,

  • dynamically generating testrequests and assertions based on database content,

  • creating custom reports after the execution of tests,

  • integrating with external tools (test management, and so on),

  • creating complex simulations of asynchronous services using Virtual Services and TestCases.

Since groovy scripts have full access to the object model, anything is possible. Unfortunately, the API documentation is only available in the javadoc format and can be difficult for new users, especially if they lack of prior knowledge of java or groovy. Let's walk through the basics of the ReadyAPI to help you get started.

Groovy

When we started to provide scripting possibilities in 2006, groovy was the logical choice. Now, this has changed and there are many viable alternatives to groovy via the Java 1.6 scripting API (JRuby, Jython, JavaScript, and so on), but since we have made our own optimizations for 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.

Things Are ModelItems

All project-related artifacts (Projects, Requests, TestSuites, and so on) are ModelItems, their interfaces are all defined in the com.eviware.soapui.model package and sub-packages (for example, see the com.eviware.soapui.model.iface package for Interface/Operation/Request related classes).

A modelItems name, description, icon, and so on, can all be accessed through the corresponding getters, for example:

log.info project.name

This would print the name of the project variable.

Obviously, depending on the type of ModelItem, properties and methods for accessing children are available. The general model for accessing children of a certain type of 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 virtual service in a project, you could use one of the following (and similar):

def mockService = project.getVirtByName( "My Virtual Service" )

def mockService = project.getVirtAt( 0 )

To iterate through all LoadTests in a TestCase, you could use:

for( loadTest in testCase.loadTestList )

log.info loadTest.name

Since groovy simplifies map access, the last one 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, i.e.:

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 in or those that are custom properties, the later can be set for the following objects, Projects, TestSuites, TestCases, Virtual Services 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 submission of a request;

  • TestRunContext – available from within all scripts in a TestCase run;

  • LoadTestRunContext – available in LoadTest setup/tearDown scripts and from the executed TestCase context via the LoadTestContext context variable;

  • MockRunContext – available in virtual service startup/shutdown scripts and Operation/VirtResponse 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.

Logging

As you have noticed, there is a "log" variable in all scripts. This is a standard log4j Logger which appends to the groovy Log at the bottom of the ReadyAPI window and can be used for diagnostic purposes, and so on.

Highlight search results