Soap UI Assertions

SOAPUI Assertions compare the parts/all of the response message to the expected outcome. We can add a variety of assertions provided by SoapUI to any test step. Each type of assertion targets specific validations on the response such as matching text, comparing XPATH or we could also write queries based on our need. When the test steps get executed, then the associated assertions receive the response for the respective test steps. If any response is failed then the respective assertion will be processed and the corresponding test step will be marked as failed. This notification can be viewed in the test case view. Also we can find failed test steps in the test execution log. The following types of assertions.

• Simple contains

• Schema compliance

• Simple not contains

• Soap Faults

• Response SLA

• XPath Match

• XQuery Match

• WS security status

• Script Assertion

• WS- Addressing Request or Response Assertion

Additionally Equals assertion is introduced in SoapUI NG Pro version.

How to Create an Assertion?

• Create a project, add WSDL

• Add Test suite, Test case and Test steps

• Run the request

To add assertions:

Click on the Add Assertions at the top of log tabs.

Configure the assertions as per the type and data required.

Assertion are very useful while performing the regression testing and to validate the test results without digging into much details

TypeDetails
Schema Compliancevalidates the response message against the definition in the WSDL and contained XML Schema
SOAP Responsechecks that the response is a valid SOAP message, always use this to make sure you are actually getting a response (if no assertions are added a connection error will not cause a failure).
SOAP Faultchecks that the response is a SOAP Fault (for negative testing)
Not SOAP Faultchecks that the response is not a SOAP Fault. Never use this assertion type together with SOAP Fault, since they will have opposite results always [i.e., compliment of each other]
xPath Matchvalidates the response message against the data returned by xPath expression & any tag in response.
xQuery Matchvalidates the response message against the data returned by xQuery expression & any tag in response.
Containsvalidates the response message contains a particular string or regular expression provided in ‘Contains’ assert condition.
Script Assertionvalidates the response message against data returned by the code of lines written in Groovy script. Useful to verify the response data against the Database which can fetched using Groovy script

Step 1:   Click on Request name to open the request editor as shown below.


Step 2:   Click on Assertions () tab at the bottom of the request editor as shown in the above image to add assertions.


Step 3:   Click on icon to add an assertion to your request. Add Assertion window appears.


Types of Assertions:

  1. Property content: Used to validate the properties in a response received after triggering a request for a particular service.
  2. Contains: Searches for the existence of a string in the property value/ tags in response xml.
  3. Not contains: Searches for the non- existence of a string in the property value/ tags in response xml.
  4. XPath Match: Match the content available in the property value/ tags in response xml with the expected value.
  5. XQuery Match: Compare content selected from target property with the expected value.
  6. Compliance, status and Standards: Checks for the schema compliances, status of the fault messages received in the responses.
  7. Invalid HTTP Status Codes: Checks that the target HTTP result code with the status code that is not defined in the list of defined codes.
  8. Not SOAP Fault: Validates that the last received message is not a SOAP fault.
  9. SOAP Fault: Validates that the last received message is a SOAP fault.
  10. Schema Compliance: Validates the response received is in compliance with the WSDL schema definition
  11. Script:
  12. Script Assertion: Runs a script to perform arbitrary validations.
  13. SLA :
  14. Response SLA: Verifies the response time with the specified or defined limit.
  15. JMS:
  16. JMS Status: Validates the JMS request of the target test step is executed successfully.
  17. JMS timeout: Checks the target test step did not take longer time duration than the defined time limit.
  18. Security:
  19. Sensitive Information Exposure: Checks the response received doesn expose any sensitive information about the target system.

COMMON ASSERTIONS:

  1. Contains – checks for the existence of a specified string
  2. Not Contains – checks for the non-existence of a specified string
  3. Reponse SLA – check the response time against a specified value
  4. XPath Match – compares the result of an XPath expression to an expected value
  5. XQuery match – compares the result on an XQuery expression to an expected value
  6. Script – runs an arbitrary script that can be used to validate the received message as desired

The above 2 assertions that can be added to the request

Assertion – SCHEMA COMPLIANCE:

Step 4:   Click on Compliance, status and standards assertion tab and choose Schema compliance assertion from the list as shown below and click Add.


Step 5:   Configure Schema Compliance Assertion window appears prompting to specify definition url to validate the response.


Step 6:   Click on OK to add the assertion to the request.


Assertion: CONTAINS

Step 4:   Click on Property content assertion tab and choose Contains assertion from the list as shown below and click Add.


Step 5:   Contains Assertion window appears prompting to specify the content to be validated in the response and click OK.


Thus assertion is added successfully to the request as shown in the image below.


MANAGE AND VALIDATE ASSERTIONS FROM TESTSUITE LEVEL:

Click on RUN button as shown in the image below to run the test cases and validate the responses received using the assertions added. The assertion results can be verified using the testcase log as shown below.

Schema Assertion- FAILED:


How to remove assertions from a request:

Step 1:  To remove assertions, double click on request name and click on Assertions tab.


Step 2:   Select the assertion and click on icon to remove the assertion.

Step 3:   Click yes in remove assertion window to confirm removal of the assertion.


Thus assertion is removed successfully.


Run TestCase to validate the contain assertion: