SoapUI Assertions

What are Assertions?

Assertions are the validation rules that apply to claims verification results and check whether the targeted web service works the same way as the expected result. Assertion can be understood through the use of checkpoints or a verification point on each parameter of validations. For example, when we send a request to a web server, the web server receives the request and generates a response. Now, we have to validate the server response result using assertion rules that contain the same result as we expect. Hence, we use assertions to validate the response.

Features of Assertions

• Assertions contain the validation rules which validate the response received by the server during the execution of the test step.
• In assertion, we can define the particular part of the response message or entire message, that should be validated.
• We can specify any number of assertions validation rules that validate test steps on different aspects of the result.
• If any test steps do not meet the received response results, the assertions test result will fail the test step. It indicates with the red color in the test execution log.

Types of Assertions

Following are the type of assertions lists used in the SoapUI tool.

1. Property Content
2. Compliance Status Standard
3. Script
4. SLA
5. JMS
6. Security

Property Content

It is used to check the properties present in the response received after triggering a particular service request.

• Contains Assertion: It is used to validate whether the specified string exists in the response xml. Furthermore, we can define regular expressions to check the existence of an expression.
• Non-Contains Assertion: It is used to verify the non-existence of a specified string in the response xml. Furthermore, we can define regular expressions in Not Contains to examine the existence of an expression.
• XPath Match Assertion: XPath match is used to select specific content from the target property and match the XPath expression's result to the expected value in the response xml.
• XQuery Match: The XQuery expression is similar to the XPath Match, used to select content from the target source and compare or match the XQuery expression result with the expected values in the response XML.
• Scripting Assertion: The Scripting assertion enables the users to run a custom script to perform a user-defined verification.

Compliance, Status and Standards

It is used to check the status of fault messages and schema compliance in response XML.

• HTTP Download All Resource: It is used to validate all html documents like images, scripts, etc. that are available after downloading the resources.
• Invalid HTTP Status Codes: The Invalid HTTP status code is used to validate whether the target test step has received a result with an HTTP code that is not available in the defined list of HTTP codes.
• Not Soap Fault: As the name suggests, a not soap fault is used to determine that no soap fault exists in the last received message.
• Soap Response: It is used to verify whether the last received message is a Soap response message, and it can only apply with any Soap requested TestSteps.
• Soap Fault: It is used to find any soap fault that exists in a last received message. It applies to Soap Test Steps as well as MockResponse Test Steps only.
• WS-Security: It is used to check whether the last received message has a valid WS-Security header. The Mock response Test Steps only support it.
• Schema Compliance: The Schema Compliance is used to check whether the last received XML message follows the WSDL or WADL compliance definition. Both SOAP and REST Test Steps use the Schema Compliance.
• WS-Addressing Request: It is used to verify if the last submitted request has a correct WS addressing header. The Mock response Test Steps only support it.
• WS-Addressing Response: It is used to verify that the last received response XML message has the correct WS address header. The Soap Request Test Steps only support it.

Script

• Script Assertion: Script assertions are used to create custom scripts that execute user-defined validation rules in a response XML file.

Security

• Sensitive Information Exposure: It is used to authenticate the received XML response messages that will not disclose sensitive information to the target system.

SLA

• Response SLA: The response SLA is used to verify that the last received message's response time is within the specified time limit. Furthermore, SLA can be implemented with script tests that send script requests to a server and receive a response.

JMS

• JMS Status: It is used to check whether the JMS request of the test phase has been successfully executed, and it is good for the test steps with the JMS endpoint. It is implemented to handle test steps request with JMS endpoint.
• JMS Timeout: The JMS timeout is used to verify that the JMS specified test steps' description does not take a longer time than the specified time duration.

JDBC

• JDBC Status: The JDBC status is used to verify that the specified test steps' request is successfully executed in a SoapUI testing tool. It can only be implemented to the JDBC TestSteps.
• JDBC Timeout: The JDBC timeout is used to verify that the specified test steps' JDBC statement does not take a longer than the specified time limit.

Contains Assertion

It is used to search the specified string present in a response XML file. Furthermore, it also uses a regular expression to check the string or text.

Following are the steps to create the Contains Assertion:

Step 1: Initial, there are no assertions in the Assertions Tab. So, click on the (+) icon to add the new assertion, as shown below.

We can also check the number of added assertions in the assertion tab.

Step 2: Select the appropriate Assertion from the Add Assertion Category like Property Content and then select the type of Property Content like Contains, as shown in the following image.

Step 3: After clicking on the Add button, it shows a popup dialog box of Contains Assertions.

Specify the string or value that we want to match with the existing web response.

Step 4: Once the OK button is clicked, it transfers control to the Request for Sum window, as shown below.

In the above image, the Contains is valid because the Response of the Request for Sum is matched with the Contains String. And if the contains is not valid, it shows an error message.

Not-Contains Assertion

It is used to search for the non-existence of the specified string or text in a web response xml file. Following are the steps to create the Not-Contains Assertion:

Step 1: For validating the Not-Contains Assertion, click on the (+) icon to add a new assertion.

Step 2: Select the Property Content and then click the Not Contains assertion, as shown below.

Step 3: After clicking the Add button, it shows a popup dialog box of NotContains Assertions.

Step 4: Specify the content or string which is not present in the web response XML file or Request for Sum and then click the OK button to check the validation, as shown below.

It validates whether the define statement Integer A is present or not. If the statement is present, it shows an error message, and if the defined string is not present in the current content, the condition for Not Contains is VALID, as we can see the image above.

XPath Match Assertion

XPath match is used to select specific content from the target property and match the XPath expression' result to the expected value in the response xml.

Following are the steps to validate the XPath Match Assertion:

Step 1: For validating the XPath Match Assertion, click on the (+) icon to add a new assertion.

Step 2: Select the Property Content and then click the XPath Match assertion, as shown below.

Step 3: After clicking on the Add button, it shows the configuration of the XPATH window.

Step 4: To declare the XML namespace in the XPath Match Configuration, click the Declare button that populates two XML namespaces in the XPath, as shown below.

Here is the declaration of the namespace used in the XPath Match:

Step 5: After populating the XML namespace, enter the XPATH node as //ns1:AddResult, that is used to search and validate the value in between <AddResult> & </AddResult>.

Step 6: After adding the //ns1:AddResult in the XPath Expression, now click the Select from Content that searches a value from the current response, as shown below.

Step 7: After clicking on the Save button, it shows the following image, in which we can see the XPath Match assertion that is VALID.

XQuery Match Assertion

The XQuery Match is similar to the XPath expression except that it uses an XQuery expression to select the string from the target response code and compare the result of an XQuery expression with an expected value.

Following are the steps to use the XQuery Match Assertion.

Step 1: For validating the XQuery Match Assertion, click on the (+) icon to add a new assertion.

Step 2: Select the Property Content and then click the XQuery Match assertion, as shown below.

Step 3: After click on the Add button, it shows the configuration of the XQuery Match.

Step 4: To declare the XML namespace in the XQuery Match Configuration, click the Declare button that populates two XML namespaces in the XQuery, as shown below.

Here is the declaration of the namespace used in the XQuery Match:

Step 5: After populating the XML namespace, now define the XQuery expression for selecting and retrieve the value that matched with the XQuery Expression, as shown:

Following is the Query structure for getting the result.

Step 6: After defining the expression, click on the Select from current button to retrieve and matched the content from the current Response XML file, as shown below.

Following is the retrieve data from the XML Response.

Step 7: After click on the Save button, it shows the below image, in which we can see the XQuery Match assertion that is VALID.