We have been working on basics of SoapUI like creating projects, adding WSDL, sending a request & receiving responses and generating test assets to go along with them so far. In this 5th SoapUI tutorial we will learn all about assertions in SoapUI. We strongly recommend you to follow the complete SoapUI training series on this page to learn all these core features. As with any testing, we have to compare what we want the system to do and what it actually is doing, to arrive at a certain validation or assertion, which is what it is called in the context of web services. As testers, it does not matter if we executed 1000 or even million test steps, but for us the result comparison is what determines the outcome of a test. Therefore, we will spend this entire article on understanding how we can do that with SoapUI, although web services can be asserted manually. Also manual assertion is time consuming when there are multiple responses and responses with large data. 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 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 sample test step assertion screen looks as below: In the above image, some of the test steps have FAILED and some of them have PASSED. The reason is assertion. As we discussed earlier, if the assert condition is not met with the expected results then the result is FAILED. What You Will Learn:Working with different kinds of assertions in SoapUI:#1.
Let us now see how to work with different types of assertions like: Firstly, we need a valid WSDL schema location. For that, we can use Medicare Supplier web service that is available at http://www.webservicex.net/medicareSupplier.asmx?WSDL. Follow the steps as below: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.To add test suite to this project follow these steps: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. Click Add Assertion option or click it from the tool bar – Add Assertion window appears on the screen with different types of assertions. 1. Click Property Content category from the list – associated assertion types and their description is displayed 2. Click Contains assertion and click 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 case 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 have seen in the test suite window, green indicates the successful execution and red denotes failure. We can use “not contains” assertion for validating request in negative scenarios. We can use GetSupplierByZipCode request to learn that. Open the request tab by double clicking on it. In the input request, enter 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 image for enlarged view) The “not contains” assertion, it is highlighted in green color as it is executed successfully.
In the configuration window, we have configured with positive expected value as below: It returns true if the expected conditional value is not found and returns false if the expected value is found in the response message. Similarly we can change the condition and run the request once again. It generates the results accordingly. XPath match assertion is little bit different in terms that it will assert the response using actual response data. For example, if we have login authentication web service that will authenticate the user credentials and send the acknowledgement 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 try to do that: Add one more assertion for the GetSupplierByCity request. In the Add Assertion window, click Property Content category and then click xpath match assertion.
The below window is displayed: The top section is the declaration part and bottom section is expected result part. When we click on the Declare option we will get some auto generated declaration scripts like below: In the above scripts, 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. As you know, if you execute GetSupplierByCity request, it will produce the response which contains the list of supplier’s personal data that belongs to New York City. Here, we have used Xpath Match expression to extract the specific supplier’s personal details from the bulk response. For that purpose we have used ns1 variable. Now click on the Select from Current button. Then SOAPUI generates the following result: Here in the response data, you can see only one supplier personal data.
Based on the number that is present inside the angle brackets, the output will be generated. By so far, this is about choosing the portion of the response that is required, how can/are we using Xpath Match assertion? Let get to that: Click on the Save button once you are OK with the response. Initially if you would 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 invalid city -“XYZ or ABC”. Run the request and check the results as well as the assertion status. We will get failure response and red status indication for assertion. Because we had 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 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 all the aggregate functions should be in lowercase. This is slightly similar to XPath Match assertion. As we have seen in the Xpath Match assertion configuration, there will be two sections – declaration and expected result. XQuery expression also supports XPath Match expression but it has its own scripting syntax which cannot be used in XPath match assertion. We will see one example to fetch all the supplier data response using XQuery expression. Look at this sample screenshot to understand better. There are more built-in functions available to use in XQuery expression.