The ReadyAPI Object Model

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

• creating controller scripts that run test cases, load tests, 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 test cases.

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, test suites, 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 load tests in a test case, 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 test suite and want to access its test cases, 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 test suite 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, test suites, test cases, virtual services and the Properties test step (these all inherit from MutableTestPropertyHolder ).

Setting/getting properties is straightforward:

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 test case run;

• LoadTestRunContext – available in load test Setup/Teardown scripts and from the executed test case 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.