As described under TestRequests, any number of assertions can be added to a TestRequest. Currently the following assertions are available:
Type | Description |
---|---|
Schema Compliance | Validates the response message against its xml-schema |
Simple Contains | Checks for the existence of a token |
SOAP Fault | Checks that the response is not a soap-fault |
XPath Match | Matches the result of a specified xpath expression against a predefined value |
They are described in detail in the sections below:
The "Schema Compliance" assertions simply 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. See the SOAP-Fault assertion below regarding validations of SOAP-Fault response messages.
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 only supported 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.
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 only one configuration-parameter which is prompted for when creating/configuring a simple-contains assertion; the token to look for.
The "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
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.1.1 xpath processor which has support for both xpath 1.0 and xpath 2.0. Download the Saxon 8.1.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):
The dialog is modeless allowing you can move focus back to soapui and for example select values from the underlying response message.
The recommended way to create an xpath assertion is as follows:
count(//ns1:Item)
in the screenshot above10
in the screenshot aboveHere 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"