08 May 2007 - 1.7.1 home user-guide eclipse jbossws intellij netbeans maven 1.X/2.X PDF files forums bugs sourceforge






Vote for soapUI at the WSJ Readers' Choice awards in the

'Best Web Services Utility' and

'Best Web Services Testing Tool'

categories

Response Assertions

As described under TestRequests, any number of assertions can be added to a TestRequest. Currently the following assertions are available:

TypeDescription
Schema ComplianceValidates the response message against its xml-schema
Simple ContainsChecks for the existence of a token
Simple NotContainsChecks for the non-existence of a token
SOAP FaultChecks that the response is a soap-fault
Not SOAP FaultChecks that the response is not a soap-fault
SOAP ResponseChecks that the response is valid SOAP Response
XPath MatchMatches the result of a specified xpath expression against a predefined value
Script AssertionAllows a custom groovy script for asserting the message exchange (soapUI Pro only)

Schema Compliance

The "Schema Compliance" assertions checks that the reponse is compliant with the response messages xml-schema definition. If not, a list of validation errors as those displayed in the validation-tab of the request editors is displayed and the assertion fails. The list of errors is also displayed in the assertion tab of the TestRequest Editor; errors are double-clickable and will highlight the row of the validation error if possible.

The assertion has only one configuration-parameter which is prompted for when creating/configuring a schema-compliance assertion; the url to the wsdl-definition to use for validation. This defaults to the URL of the definition for the containing TestRequests' Operations' Interface.

Schema Compliance validation is currently targeted at Basic-Profile compliant wsdls/messages and thus only supports for literal-encoded messages (both rpc and document), validation of SOAP-encoded messages is not supported and will result in a validation error in any case.

Be aware of the fact that a SOAP-Fault will only be a schema validation if the detail element contains a message part that is defined in the corresponding binding and not compliant with its corresponding schema definition (see the SOAP-Fault assertion below regarding validations of SOAP-Fault response messages).

Simple Contains

The "Simple Contains" assertion simply checks for the existance of a specified substring in the received response. No xml-parsing/validation is performed at all

The assertion has 2 configuration-parameter which is prompted for when creating/configuring a simple-contains assertion; the token to look for and if the search should be case-insensitive.

Simple NotContains

The "Simple NotContains" assertion simply checks for the non-existance of a specified substring in the received response. No xml-parsing/validation is performed at all.

The assertion has 2 configuration-parameter which is prompted for when creating/configuring a simple-notcontains assertion; the token to look for and if the search should be case-insensitive.

SOAP Fault

The "SOAP-Fault" assertion simply checks that the received response is a SOAP Fault.

This assertion has no configuration parameters.

Not Soap Fault

The "Not SOAP-Fault" assertion simply checks that the received response is not a SOAP-Fault. This should be used in conjunction with the "Schema-Compliance" since a SOAP-Fault does not get validated against any schema (unless there is a Fault-Part defined in the WSDL and that Fault-Part is present in the response) This assertion has no configuration parameters.

SOAP Response

Validates that the response is a valid SOAP Message. This is the minimal assertion that should be added to catch empty responses or HTTP error pages. This assertion has no configuration parameters.

XPath Match

The "XPath Match" assertion allows specification of an XPath expression to be evaluated against the received response message and compare its result to a predefined value. Expressions can select everything from attribute values, make boolean evaluations or select the entire response-body. (XmlUnit is used internally for comparing xml-elements/nodes/hierarchies)

soapUI internally uses the Saxon 8.6.1 xpath processor which has support for both xpath 1.0 and xpath 2.0. Download the Saxon 8.6.1 release which contains extensive documentation on which features that are supported.

The configuration-dialog for the xpath-match assertion is divided into 2 areas (see below); the top xpath area which contains the desired xpath expression and the bottom result area which contains the expected result.

The following actions are available at the bottom (left to right):

  • Select XPath - opens the XPath Selector for the current response (soapUI Pro only)
  • Select from current - evaluates the specified xpath expression against the current response message (if available) for the underlying request. The result is written into the result area of the configuration dialog.
  • Test - evaluates the specified xpath expression against the current response message (if available) for the underlying request and compares that result with the value specified in the result area. This is essentially the same comparison that is performed during a "real" assertion.
  • Declare - adds namespace declaration for all namespaces currently defined in the underlying response message to the xpath expression. Saxon uses this syntax for namespace declarations so you can later use them in your xpath expression.
  • Save - saves the current xpath/result values and closes the dialog.
  • Cancel - discards the current xpath/result values and closes the dialog.

The dialog is modeless allowing you can move focus back to soapUI and for example select values from the underlying response message.

Creating XPath Assertions

The recommended way to create an xpath assertion is as follows:

  1. Submit the TestRequest and await its response (so you have response to test)
  2. Create the XPath Assertion and begin by adding namespace declarations to the xpath expression with the "Declare" button
  3. Now add the actual xpath expression after the namespace declarations, count(//ns1:Item) in the screenshot above
  4. Use the "Select from current" button to evaluate the xpatch expression against the available result and check that it returns what you expect; 10 in the screenshot above
  5. Double-check by pressing the "Test" button which should return an OK message since the test will compare the xpath selection result with the previously selected value

With soapUI Pro the creation is greatly simplified through the Add Assertion Wizard which performs step 2 and forward through a simple right-click action.

XPath Assertion Examples

Here are some examples expressions for a search-result from the amazon web-service returning 10 hits when searching on books with the word "Oxford" in their title. The following assertions could be created;

Validate that the result contains 10 hits

declare namespace ns1='http://webservices.amazon.com/AWSECommerceService/2005-07-26';
count(//ns1:Item)

which will return "10".

Validate that the ProductGroup element always is "Book":

declare namespace ns1='http://webservices.amazon.com/AWSECommerceService/2005-07-26';
count(//ns1:ProductGroup[text()!='Book'])

which will return "0".

Validate that DetailPageURL always starts with 'http://www.amazon.com/exec/obidos':

declare namespace ns1='http://webservices.amazon.com/AWSECommerceService/2005-07-26';
count(//ns1:DetailPageURL) = count(//ns1:DetailPageURL[starts-with(text(), 'http://www.amazon.com/exec/obidos')])

which will return "true"

Script Assertion

soapUI Pro includes a Script Assertion that allows for arbitrary validations (see examples below). When creating/double-clicking a script assertion, a groovy script editor is shown as follows;

The assertion script can be run against the latest message exchange with the run button in the top left

The script has access to the following objects:

  • messageExchange : the MessageExchange for the current request/response. Gives direct access to message content, HTTP Headers, Attachments, etc.
  • context : the TestRunContext running the current TestCase, this will for now always be an instance of WsdlTestRunContext
  • log : a standard log4j Logger object available for logging arbitrary information

An assertion script should throw en Exception with the failure message to fail the assertion. One can also use the built in Groovy assert statement for an easy assertion syntax as shown in the examples below. If the assertion is valid, either return nothing or a status message that will be shown in the TestCase Log.

Assertion Script Examples

Validate a certain response time:

assert messageExchange.timeTaken < 400

Validate extistence of a response HTTP Header:

assert messageExchange.responseHeaders["x-amz-id-1"] != null


Next: PropertyTransfers