In SoapUI, assertions are used to validate the message that a Test Step receives during execution, usually by comparing sections of the message (or the full message) to an expected value. A sample Test Step can include any number of assertions, each validating a particular element or content of the answer. The parts/all of the answer responses are compared to the expected outcome in assertions.

Some of the important assertions present in SoapUI are as follows:

• WS security status: SoapUI manages WS Security CONFIGURATIONS at the project level, allowing them to be utilised in several locations within a project:
  • For incoming and outgoing requests, as well as responses.
  • Incoming MockServices requests and their MockResponses.
  • In the SOAP Monitor, for monitored requests and their monitored answers.

On the project level, there are four sub-tabs under the WS Security Configurations tab:

1. Outgoing WS-Security Configurations: configurations for outgoing messages, such as requests and MockResponses. Encryption, signing and adding SAML, timestamp, and username headers are all done with this configuration type.
2. WS Security Configurations for Incoming Messages: configurations that should be applied to incoming messages, such as responses, MockRequests, or monitored requests and responses. This configuration type is used to decode and validate incoming messages' signatures.
3. Keystores: Encryption, DECRYPTION, and signature keys are stored in keystores.
4. Truststores: Truststores used for signature verification.

• XPath Match: The XPath ASSERTION applies a defined XPath expression to the incoming message and compares the nodes to a predetermined value. The assertion succeeds if the values match; else, it fails. Let us  take a look at a login response message that we would like to verify:

Essentially, we want to look for the loginResponse and sessionid components in the SOAP Body, but ignore the sessionid's actual value because it will change between requests.

• XQuery Match: To pick information from the target property, XQuery employs an XQuery expression. It compares an XQuery expression's result to an expected value and it is applicable to any property CONTAINING XML.
• Script Assertion: The Script Assertion enables arbitrary message validation, such as message content, HTTP headers, and so on. Validation scripts are written in the project scripting language (Groovy or JavaScript) and run when the assertion status of the containing sampler Test Step changes.
• Simple Contains: It searches for the existence of a string in the property value and supports regular expressions. It is applicable to any property.
• Soap Faults: Soap Faults check whether the response is a SOAP Fault (used for negative testing).
• Not Soap Faults: Not Soap Faults check whether the response is not a SOAP Fault.
• Response SLA: Response SLA checks the response time against a particular value which is given.
• WS Addressing Response: WS Addressing Response validates the availability of WS Addressing Headers in the response
• Schema Compliance: Schema compliance validates the response message against the WSDL (Web Service Description Language) definition and the XML Schema it contains.
• Simple not Contain: It searches for the non-existence of a string in the property value and supports regular expressions. It is applicable to any property.
• SOAP Response: Verifies that the response is a genuine SOAP message; used to ensure that we are receiving a response (if no assertions are added a connection ERROR will not cause a failure).
• JMS Timeout: When utilising a JMS endpoint with a response channel provided, this assertion verifies that the response is received within the specified time.
• JMS Status: This assertion verifies that no JMS related issues occurred when using a JMS endpoint.