Understanding Assertions in SoapUI – SoapUI Tutorial #5

This article is all about understanding assertions in SoapUI. Let’s get started. 

So far, we have been working on the basics of SoapUI such as creating projects, adding WSDL, sending a request & receiving responses and generating test assets to go along with them.

In this 5th SoapUI tutorial, we will learn all about assertions in SoapUI. However, we strongly recommend that you follow the complete SoapUI training series on this page to learn all these core features.

Understanding Assertions in Soap UI

Introduction to Assertions

As is the case with any kind of testing, we have to compare what we want the system to do and what it is doing, to arrive at a certain validation or assertion. As testers, it does not matter to us if we execute 1000 or even a million test steps, the result comparison is what determines the outcome of a test.

Therefore, we will spend this article on understanding how we can do that with SoapUI, even though web services can be asserted manually. Also, manual assertions are time-consuming when there are multiple responses and responses with large data. The SoapUI assertions are excellent at overcoming these shortfalls.

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 assertions will be processed and the corresponding test steps will be marked as failed. This notification can be viewed in the test case view. We can also find the failed test steps in the test execution log.

The sample test step assertion screen looks like the image given below:

In the above image, some of the test steps have FAILED and some of them have PASSED. The reason is the assertion.

As discussed earlier, if the assert conditions are not met with the expected results then the results are FAILED.

Working With Different Kinds Of Assertions In SoapUI

Let us now see how to work with different types of assertions such as:

• Contains and Not Contains assertions
• XPath match and
• XQuery match assertions.

First, we need a valid WSDL schema location.

Follow the steps given below:

Step 1. Create a new SOAP project by pressing CTRL + N and follow the steps. After creating the project, SOAPUI generates the list of interfaces and the corresponding requests.

Step 2. To add a test suite to this project, follow these steps:

• Right-click on the interface name MedicareSupplierSoap
• Click Generate Testsuite option from the context menu
• Click OK in the window below that comes up:

• In the next popup, you will need to enter your desired test suite name and click OK
• SOAPUI PRO will generate the test suite along with the requests in the navigator panel.
• Under the test suite, you will see some of the test steps with the SOAP request step.

Step 3. To execute this test suite, double-click on the request step and specify the input value in the respective location. For instance, open GetSupplierByCity request and enter New York between the city tags.

• Start this request by clicking on the RUN icon – this will receive a response.
• Now let’s add assertions. To do so, click on the Assertions tab present at the top of log tabs.
• On right-clicking, a pop-up menu will appear with some basic assertion related options below:

#1) Contains Assertion

Click Add Assertion option or click it from the toolbar – Add Assertion window appears on the screen with different types of assertions.

1. Click on the Property Content category from the list – associated assertion types and their description is displayed

2. Click Contains assertions and click the Add button

3. This is the assertion configuration window. Here itself we have to specify the expected condition based on the response.

For example, let me enter New York text in this text field. Ignore cases in comparison checkbox will ignore even if the expected value is in upper case or lower case.

4. Now execute the test suite and verify the results. As you can see in the test suite window, green indicates successful execution and red denotes failure.

#2) Not Contains Assertion

We can use “not contains” assertion for validating requests in negative scenarios. We can use GetSupplierByZipCode request to learn more about it.

Open the request tab by double-clicking on it. In the input request, enter an invalid zip code in the appropriate location, such as 10029. Run this request now. Check the response data which has the supplier details for the given zip code – take a look at the image below:

(Click on the image for an enlarged view)

The “not contains” assertion, it is highlighted in green colour as it is executed successfully.

In the configuration window, we have configured with positive expected value as below:

It will return true if the expected conditional value is not found, and will return false if the expected value is found in the response message.

Similarly, we can change the condition and run the request once again. It will generate the results accordingly.

#3) XPath Match Assertion

XPath match assertion is a little bit different in terms of how it will assert the response using actual response data.

For example, if we have a login authentication web service that will authenticate the user credentials and send the acknowledgment to the client with some Boolean type of data which may be TRUE or FALSE in the form of XML.

As you know XML documents are built by tags. So when specifying the expected value in the configuration, it should be in the form of XML.

Let’s try to do that:

Add one more assertion to the GetSupplierByCity request. In the Add Assertion window, click on the Property Content category and then click XPath match assertion.

The following window is displayed

The top section is the declaration part and the bottom section is the expected result part.

When we click on the Declare option, we will get some auto-generated declaration scripts like the one given below:

declare namespace soap=’http://schemas.xmlsoap.org/soap/envelope/’;
declare namespace ns1=’http://www.webservicex.net/’;

In the above scripts, the first line denotes the response that should be XML data and enclosed SOAP tags. In the next line, the whole response will be assigned or copied into the ns1 namespace variable during the execution. If we want to filter particular data from the whole response, we have to add the following script.

//ns1:SupplierData[1]

As you know, if you execute the GetSupplierByCity request, it will produce a response that contains a list of the supplier’s personal data that belongs to New York City.

Here, we have used the XPath Match expression to extract the specific supplier’s personal details from the bulk response. For this purpose, we have used an ns1 variable. Now click on the Select from the Current button.

Then SOAPUI generates the following results:

<SupplierData xmlns="http://www.webservicex.net/"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 
<SupplierNumber>0127051883</SupplierNumber>
<CompanyName>KMART CORP</CompanyName>
<Address1>250 W 34TH ST</Address1>
<Address2/>
<City>NEW YORK</City>
<Zip>NY</Zip>
<ZipPlus4>10119</ZipPlus4>
<Telephone>0002</Telephone>
<Description>(212)760-1242</Description>
<IsSupplierParticipating>04</IsSupplierParticipating>
</SupplierData>

Please refer to the screenshot given below:

Here in the response data, you can see only one supplier’s personal data. Based on the number that is present inside the angle brackets, the output will be generated.

So far, this is about choosing the portion of the response that is required, how can/are we use XPath Match assertion?

Let’s get to that: Click on the Save button once you are OK with the response.

Initially, if you have executed this service after configuring XPath match assertion with no changes, the result will be a successful response, status highlighted in green.

But let’s change the input parameter in the input request to something that is an invalid city -“XYZ or ABC”. Run the request and check the results as well as the assertion status. We will get a failure response and a red status indication for the assertion. This is because we have already specified that the particular supplier data should be present in the service response in the expected result configuration and when the city name is invalid, that supplier is clearly not present.

This is how we can assert the XML response using the XPath Match expression assertion. Agreed that this is quite simple to start with but if you try with different service responses, you will get a much better idea.

We can also use aggregate functions in XPath Match expression. They are Sum, Min, Max, Count and Avg.

For example, if we want to know the total number of suppliers count in the expected results, write the following script.

count (//ns1:SupplierData) and it returns 536 as a result. Remember that all aggregate functions should be lowercase.

#4) XQuery Match Assertion

This is slightly similar to the XPath Match assertion. As we have seen in the XPath Match assertion configuration, there will be two sections – declaration and expected result.

• Add a XQuery Match assertion to the request
• In the configuration window, click the declare button and write the following script
• Now click Select from the Current button
• SOAPUI generates a response to the script

XQuery expression also supports the XPath Match expression but it has its own scripting syntax which cannot be used in the XPath match assertion.

For Example

We will see one example to fetch all the supplier data response using XQuery expression. Take a look at this sample screenshot to get a better understanding.

Actual Script

declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/';
declare namespace ns1='http://www.webservicex.net/';
 
<resultData>
{
for $x in //ns1:SupplierData
return $x
}
</resultData>

There are more built-in functions available to use in XQuery expression. They are where, order by, for, return and so on.

Conclusion

Well, those were the most commonly used assertions for you.

Assertions are most important to predict the expected result of the web services accurately. That’s the reason it is one of the key features in SOAPUI PRO.

Next tutorial: In the next tutorial, we will get groovy with scripting basics and more.

Hope you found this article useful. Your feedback, questions, and suggestions are always welcome. Please post them in the comments section below. We would love to hear from you.