My SoapUI Thoughts on Effective Testing in SoapUI

Testing OPTIONS and PATCH Methods

When we assembled our service definition, we included the HTTP methods OPTIONS, PATCH and HEAD. Now is as good a time as any to include them in our tests.


  • A test case configured to test the todos resource


  • An understanding of how to implement tests for the OPTIONS and PATCH methods.


The OPTIONS method returns the list of methods supported by the specified resource. From a testing perspective, the main benefit is to let you know that you’re testing all the methods that have actually been implemented. You can also run it to detect if your developers have added or removed any methods from the API from one version to the next. Sometimes they do these things without telling you, the little scamps.

We can include the OPTIONS method in the Todos test case. Create a REST test step called OPTIONS and select the OPTIONS request in the New RestRequest dialog. Move it up in the test case so that it’s the first REST step, immediately following the Datasource driver script step. The new test step should look like this. OPTIONSMethod01 The salient aspect of the OPTIONS method is that the value of interest is returned as part of the header. In SoapUI, the contents of header fields are available via the messageExchange variable, which in turn is exposed directly in script assertions. (I’ve seen some online commentary claiming that the messageExchange variable is only available in script assertions. As we will see when implementing a datasink, this is not the case.) For our immediate purposes, a script assertion is a useful way to access the response header.

Run the step by itself and look at the raw response. You’ll see a line in the header like this:

Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE

This line contains the list of methods supported by the todos resource. A script assertion can capture the value of the response by creating a property on the test case called HTTP Options and copying the current value into it. Subsequent runs of the test case will cause the script assertion to fail if the value of the response is different from what was originally captured.

Create a script assertion on the OPTIONS test step containing the following code.

final def tc = context.getTestCase(),
		responseHeaders = messageExchange.getResponseHeaders(),
		oldHTTPOptions = tc.getPropertyValue( "HTTP Options" ),
		newHTTPOptions = responseHeaders[ "Access-Control-Allow-Methods"]?.
if( oldHTTPOptions ) {
	assert newHTTPOptions == oldHTTPOptions
tc.setPropertyValue( "HTTP Options", newHTTPOptions )

I’ve renamed the script step HTTP Methods. You can run the script, the test step, or the entire test case and see that the test case now contains an HTTP Options property. The contents of this property will be the baseline against which future calls to the OPTIONS method are compared.

For consistency with the other REST test steps, I’ve also created an HTTP Status assertion to check that the method returns 204 – No Content.


The PATCH method allows a caller to update part of a specified resource. This is close to the behaviour of the PUT method. The difference in theory is that PUT replaces the entire resource with the new content in the request whereas PATCH applies only the specified differences, but not all implementations preserve this distinction. In order to test this method conclusively, you need to ask your developers whether you can mix’n’match your PUT and your PATCH. (When approaching the developers, make sure you express your request for clarification in exactly these terms.)

We can use the Todos test case to run the PATCH method. Create a REST test step called PATCH and select the PATCH request in the New RestRequest dialog. Move it up in the test case so that it’s between the GET and the PUT REST steps. The new test step should look like this. PATCHMethod01.jpg This test step will modify the title of the specified resource by adding “ and pick up the milk.”, but will not change any other fields in the record. You should assert on the new content via a JSONPath match assertion like this. PATCHAssertion01.jpg

The last remaining HTTP method – HEAD – requires a more involved explanation, and will be dealt with as part of the discussion in the page relating to compiling a JAR file.


Having seen how to read test data from CSV files, it’s worth looking at how to do this with spreadsheets.