Mastering Assertions in SoapUI

How to add assertions in SoapUI?

Software testing plays a vital role in ensuring the quality and reliability of software applications. However, efficient assertion management is crucial to obtaining accurate testing outcomes. This guide aims to help you understand different types of assertions and provides a step-by-step process to manage them successfully in SoapUI.

Table of contents

• Understanding Assertions
• Types of Assertions in SoapUI
• Contains Assertion
• Not Contains Assertion
• XPath Match Assertion
• Scripting Assertion
• Troubleshooting SoapUI Assertions
• Common pitfalls to avoid
• Conclusion

Understanding Assertions: why are they important?

Assertions are a critical aspect of testing in SoapUI and similar tools. In brief, an assertion is a checkpoint that verifies whether a web service or API response meets the expected criteria. This verification ensures the accuracy and reliability of your tests. Without assertions, you may encounter false positives or negatives, which can be misleading and divert your ability to identify and fix issues in your application.

Assertions serve several essential purposes:

Validating response data

Assertions allow you to validate the data in a web service or API call response. This is crucial for ensuring that the service is providing the correct data.

Verifying response status

Assertions can confirm whether the HTTP status code is as expected, such as a 200 OK response for a successful request or a 404 Not Found for a missing resource.

Checking response times

You can use assertions to verify the response time, which is vital for performance testing. Slow responses can indicate bottlenecks or inefficiencies in your system.

Ensuring proper error handling

Assertions can help you verify that error messages or codes are correctly returned when errors occur, ensuring proper application handling.

Security testing

Assertions can be used to test for security vulnerabilities, such as checking for proper authentication and authorization.

Data transformation and formatting

If your web service transforms data in any way, you can use assertions to ensure that the data is correctly converted or formatted.

Now that we understand the importance of assertions, let’s delve into the various assertions available in SoapUI and how to use them.

Types of Assertions in SoapUI

Indeed, in the open source version of SoapUI, several commonly used assertion types help validate responses thoroughly. These assertions are essential for ensuring your web services and APIs function correctly.

Let’s explore a few of these popular assertion types:

• Contains Assertion
• Not contains Assertion
• XPath Match Assertion
• Scripting Assertion

Contains Assertion

The CONTAINS assertion checks if the response contains a specified string or pattern. It helps verify the presence of specific content in the response data. For example, you can use it to confirm that an error message or a particular element is present in the response.

Add assertion

• First, open your SoapUI project and navigate to the specific test step within a test case where you want to add the Contains Assertion.
• Right-click on the test step and navigate to the editor page with the test scripts below. Then click the + icon to add an assertion.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:web="http://www.dataaccess.com/webservicesserver/">
   <soap:Header/>
   <soap:Body>
      <web:NumberToWords>
         <web:ubiNum>46</web:ubiNum>
      </web:NumberToWords>
   </soap:Body>
</soap:Envelope>

Select Contains Assertion

• Select the Assertion Category as Property Content.
• Select the Assertion Type as Contains.
• Click Add.

Validate contains

Let us validate the contents tab by putting some string values. For example, check if the string forty six exists in the response. Then click OK.

The assertion is immediately executed upon adding it and shows its status as VALID or INVALID.

Let us say we change the content to forty seven and see what happens.

The Assertion is executed, and the result is thrown to the user. The Assertion has failed since we don’t have string forty seven within the response.

Not Contains Assertion

As the name suggests, the NOT CONTAINS assertion validates that a particular string or pattern is not present in the response. This is beneficial for ensuring that undesired content is not found in the response, which can be necessary for error handling and data cleanliness.

Add Assertion

• First, open your SoapUI project and navigate to the specific test step within a test case where you want to add the Contains Assertion.
• Right-click on the test step and navigate to the editor page with the test scripts below. Then click the + icon to add an assertion.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:web="http://www.dataaccess.com/webservicesserver/">
   <soap:Header/>
   <soap:Body>
      <web:NumberToWords>
         <web:ubiNum>int A</web:ubiNum>
      </web:NumberToWords>
   </soap:Body>
</soap:Envelope>

Select Not Contains Assertion

• Now, after clicking on the Add New Assertions button,
• Select the Assertion Category as Property Content
• Select the Assertion Type as Not Contains
• Click Add

Validate the contents

Let us validate if the string int A exists in the response and click OK.

When an assertion is added, it executes and displays the result.

Now, let us change the contents of the Not Contains Assertion and see what happens. We will check for the non-existence of the string Four million five hundred and sixty one thousand nineteen.

The string is present in the response. Hence, the NOT Contains assertion will fail, as shown below.

XPath Match Assertion

The XPath Match assertion is used in SoapUI to validate XML or JSON responses by applying an XPath expression to the response data, ensuring that specific elements or values meet the expected criteria.

Adding an XPath Match Assertion

• After clicking on the Add New Assertions button, select the Assertion Category.
• Choose the Assertion Type – in this case, select XPath Match.
• Click Add.

Declaring XML Namespace

Before adding a SoapUI XPath expression, it’s essential to properly declare the XML namespace to identify elements and attributes in XML documents. An XML namespace is a collection of names recognized by a Uniform Resource Identifier (URI) reference.

To declare XML namespaces:

• Click the Declare button in the Add XPath window. This action automatically adds the necessary namespace declarations for you. Alternatively, you can manually declare namespaces.
• Upon clicking Declare, two namespaces will be added: one for the schema URL and the other for the actual web service URL. Use the namespace corresponding to the web service’s location when referencing XPath.

For Example:

declare namespace soap= http://schemas.xmlsoap.org/soap/envelope/;
declare namespace ns1= http://tempuri.org/;

Defining the XPath Expression

• Enter the XPath of the XML node you need to validate. For instance, if you want to validate the value within the AddResult element, use an XPath like //ns1:AddResult, where ns1 corresponds to the previously declared namespace pointing to the URL of declare namespace ns1.
• After entering the XPath, click Select from current to capture the current response value for comparison.

Confirmation and modification of expected value

• After selecting from the current response, the current value will be shown as the expected value. Modify it if necessary.
• Click Save to save your XPath Match assertion.

Viewing the added assertion

• The added XPath Match assertion in SoapUI will be displayed within the test step’s assertions, as shown in your SoapUI project.
• Following these steps, you can effectively use the XPath Match assertion in SoapUI to validate specific elements within XML or JSON responses.

Scripting Assertion

Scripting assertions provide a broader scope for creating custom validation logic. You can use scripts to validate various aspects of the response, which might be challenging to achieve with other built-in assertions. It is a powerful tool for performing complex and dynamic validations.

SoapUI uses either Groovy Scripting or JavaScript for scripting assertions. The scripting technique is adopted to develop a framework for testing SOAP.

When to use a script assertion

Scripting assertions are used under the following circumstances.

• Scripting allows the user to perform some operations before and after executing a TestCase using setup and tear-down methods. Set up is a procedure that is executed before implementing a particular method(for example – Object creation and Initialization), while tear down is a procedure that is executed after executing the method(e.g., Destroying objects and cleaning up). This feature is unavailable in other Assertion types and can only be done through coding.
• It allows users to open/close a Project to initialize or clean Project-related settings and work with environmental variables, which is very helpful during scripting.
• It helps us assert dynamic Response content.
• Scripting assertions are used to create user-defined assertions that SoapUI does NOT predefine.

How to use a script assertion

Add Assertion

• First, choose the test step against which you want to add the scripting assertion.
• Click the Add Assertion button.
• In this case, choose Script.
• Select SoapUI Script Assertion, which has no associated sub-types.
• Click Add.

Write the Validation Script

Write a Groovy script to validate the response XML in the Scripting Dialog. Knowing Groovy scripting or JavaScript is recommended before attempting to write your script.

//Define Groovy Utils and holder for validating the XML reponse content
def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context)
def holder = groovyUtils.getXmlHolder(messageExchange.responseContent)

//Define the NameSpace
holder.namespaces["ns1"] = "http://tempuri.org/"

//Get the Value of the Node 'AddResult' and assign to a variable
def addResult = holder.getNodeValue("//ns1:AddResult")

//print the value of the result in the Output panel
log.info "The result value for integers is " + addResult

//Comparing the value to print 'Pass' or 'Fail'
if(addResult=="46")
{ log.info "Pass" }
else
{ log.info "fail"}

Use the script to define Groovy Utils and a holder for validating the XML response content. Then click the green play button at the top left corner to trigger the script execution.

The script’s output will be displayed in the Output pane, including the Conversion Value and the final result (Pass or Fail). An information message will appear, stating that the Script Assertion Passed. Then click OK.

The status of added Assertion in SoapUI will be displayed below.

Troubleshooting SoapUI assertions

Indeed, here’s a list of common errors and troubleshooting tips when working with assertions in SoapUI, along with actual error messages in code blocks:

No match in current assertion error

This error occurs when you use an assertion, such as an XPath or XQuery, to find a specific element or value in the response, but the specified element or value does not exist.

No Match in Current Assertion

Troubleshooting:

• Double-check the assertion conditions, especially the XPath or XQuery expression, to ensure it accurately represents the element you are trying to match.
• Verify the structure of the response to see if the expected element or value is present.
• Ensure that the response data conforms to the expected format; sometimes, small changes in the response structure can cause this error.
• Using a data source, ensure the test data contains the expected elements or values.

Missing property error

This error occurs when you try to assert a property that doesn’t exist in the response.

Missing property: 'propertyName'

Troubleshooting:

• Verify that the property you’re trying to assert exists in the response.
• Check the spelling and case sensitivity.

Generating bytecode error

This error message indicates an issue after upgrading to SoapUI version 5.6.0. This error may appear despite not using explicit assertions in your SoapUI projects. The error points to a problem with bytecode generation during the execution of the project, possibly related to internal processes within SoapUI.

java.lang.Exception: java.lang.AssertionError: Failed generating bytecode for <eval> : 345

Troubleshooting:

• Start by upgrading or reinstalling SoapUI to the latest version.
• Review your project for dependencies, custom scripts, and specific test steps that might be causing the issue.
• Ensure your system environment variables are correctly configured. If the problem persists, seek assistance from SoapUI support or the community forums for further guidance.

Common pitfalls to avoid

While working with assertions in SoapUI, there are some common pitfalls to watch out for:

Overly Complex Assertions: Avoid creating excessively complex and difficult-to-maintain assertions. Simplicity is key.

Ignoring Negative Testing: Remember to test for negative scenarios, such as what happens when the service returns an error response.

Failure to Handle Dynamic Data: Web services often return dynamic data, such as timestamps or unique identifiers. Consider using regular expressions or XPath expressions that account for these variations.

Final thoughts on managing assertions in SoapUI

Assertions are critical in ensuring the reliability and functionality of web services and APIs tested using SoapUI. By strategically placing, organizing, and managing assertions, you can enhance the effectiveness of your testing efforts. Regularly reviewing and updating your assertions as the services evolve is essential to maintain the accuracy and relevance of your tests. Mastering the art of managing assertions in SoapUI is fundamental to achieving successful API testing and quality assurance.

Related articles

• Mastering Postman assertions
• Intro to SoapUI
• SoapUI security testing
• Automating API testing with SoapUI

SoapUI assertions guide