In the previous two articles, we covered the details of Test Specific Assertions, which were applicable only for a specific kind of TestCase or WebService under test. All the assertions mentioned in the article “SoapUI Test Specific Assertions: REST Services” are only applicable for REST WebServices and all the assertions mentioned in the article “SoapUI Test Specific Assertions: SOAP Services” are only applicable to SOAP WebServices. Now, SoapUI provides few other assertions also, which are applicable for both SOAP and REST services and are known as the SoapUI Common Assertions. In this article, we will understand the usage of all those common assertions by covering the details under the following topics:
- What are the common Property Content Assertions in SoapUI?
- What is Contains Assertion in SoapUI?
- Additionally, what is Not Contains Assertion in SoapUI?
- What is XPath Assertion in SoapUI?
- What is XQuery Match Assertionin SoapUI?
- Similarly, what are the common Compliance, Status, and Standard Assertions in SoapUI?
- What are HTTP Status Codes assertions provided by SoapUI?
- Additionally, what is the Schema Compliance assertions in SoapUI?
- What are the common SLA Assertions in SoapUI?
As all these assertions are applicable for both SOAP and REST services, we will be using the following information for validation of all these assertions:
- The REST project created using URI: “http://bookstore.toolsqa.com/BookStore/v1/Books” and the SOAP project created using WSDL: “http://bookstore.toolsqa.com/BookStoreService.wsdl” as per the details mentioned in the article “SoapUI: Working with Projects.“
- You can refer to the sample output of the REST project from the article “SoapUI Test Specific Assertions: REST Services,” and the sample output of the SOAP project from the article “SoapUI Test Specific Assertions: SOAP Services.”
What are the common Property Content Assertions in SoapUI?
As we already know, the Property Content Assertions validate the content of the response received. SoapUI provides multiple content assertions which are applicable for both SOAP and REST requests. Let’s see in the sections below, how we can use those assertions?
What is Contains Assertion in SoapUI?
The Contains Assertion searches for the existence of a string token in the property value.
Consider a scenario that in BookStore Service, we need to check whether a book with the author name “Richard E. Silverman” exists?
Let’s follow the steps mentioned below to validate the same using “Contains” assertion:
1) First, navigate to the Add Assertion dialogue box. After that, click on the “Contains” assertion under the “Property Content” assertion category, as highlighted below:
2) Secondly, click on the “Add” button, and it will display the “Contains Assertion” dialogue box, as shown below:
3) Thirdly, enter the name of the author “Richard E. Silverman” in the “Content” section. It is the search string that you want to validate in the response of the WebService.
4) Fourthly, in the above dialogue box, you will see two checkboxes also. They are:
- Ignore case: If you select the Ignore case checkbox, it will validate the string by ignoring the case. Suppose you type “richARD E. SilVerMan” in the Content textbox and check the “Ignore case in comparison” checkbox. Additionally, it will ignore the case and will only check for the value of the string entered.
So, the assertion will pass as the characters in the string are the same if we ignore the case.
- Regular Expression: If you want to validate the output based on a RegEx, you can check this Checkbox and then specify your regular expression in the Content section. SoapUI follows the regular expression patterns specified by Oracle. For example, if we want to validate that the book service response contains “O’Reilly” in the response, you can specify “.*O’Reilly.*” as a RegEx in the Content section, as shown below:
So, we can validate the existence of a string in the response of the WebService by using the Contains assertion, and we can use this for both SOAP and REST Webservices.
What is Not Contains Assertion in SoapUI?
In contrast to Contains assertion, the Not Contains assertion searches for the non-existence of a string in the property value. Moreover, this assertion will pass if the response does not contain the specified value.
Let’s assume; we want to validate that there is no Book with the title “Groovy Book” in the response of the book store service, we can use this assertion to validate the response of the BookStore API.
Let’s follow the steps mentioned below to validate the same using “Not Contains” assertion:
1) Firstly, navigate to Add Assertion dialogue box and click on the “Not Contains” assertion under the “Property Content” assertion category, as highlighted below:
2) Secondly, click on the “Add” button, and it will display the “NotContains Assertion” dialogue box, as shown below:
3) Thirdly, enter the name of the string ” Groo Book” in the “Content” section. It is the search string that you want to validate that doesn’t exist in the response of the WebService.
Note: The two checkboxes(Ignore Case & RegEx) here works in the same way, as they were with the Contains assertion.
4) Fourthly, clicking on the “OK” button will execute the assertion against the WebService response and will show the result, as shown below:
5) So, as long as the string is not present in the response of the target service, the assertion will pass.
What is XPath Match Assertion in SoapUI?
The XPath Match assertion permits you to use an XPath expression to select the content from the target response’s specific node and compare it with the value you expect.
Suppose you want to validate that ISBN of the first book present in the response of BookStore API is not null. We can quickly validate the same using the XPath assertion.
Let’s follow the steps mentioned below to validate the same using “XPath Match” assertion:
1) Firstly, navigate to Add Assertion dialogue box. After that, click on the “XPath Match” assertion under the “Property Content” assertion category, as highlighted below:
2) Secondly, click on the “Add” button, and it will display the “Xpath Match Configuration” dialogue box, as shown below:
Where,
- Declare: Clicking on this button fetches and populates the namespace automatically. If you are confident of the details of the namespace, you can type it manually, otherwise just click on the “Declare” button and it will populate the namespace details as shown below:
- The namespace for the SOAP service will be populated, as shown below:
-
- Similarly, the namespace for the REST service will be populated, as shown below:
After declaring the namespace, we can specify XPATH of the desired node in the section XPath Expression.
-
- You can specify a sample XPATH “//ns1:BooksResult[1]/ns1:Books[1]/ns1:CustomBookModel[1]/ns1:Isbn” for the SOAP service as shown below:
-
- Similarly, you can specify a sample XPATH “//ns1:books//ns1:e[1]/ns1:isbn” for the REST service as shown below:
Note the usage of namespace ns1 in both cases. For accessing the nodes, usage of the namespace is mandatory.
- Select from current: By clicking on this button, it will automatically select the value of the node as mentioned above in the Expected Result section, which is isbn in the above case. Additionally, it will select the value of node isbn as “9781449325862“. If you don’t want to auto-select the value by clicking this button, you can even type the expected result manually also.
- Test: By clicking on the “Test” button, you can test the output, if the assertion passes, it will show the below success alert :
Or if the assertion fails, it throws Error and shows a dialogue box, as shown below:
- Optional Checkboxes: The Expected Result section provides some checkboxes also, which provides additional help in validating the assertion. Let’s understand the details of these checkboxes:
- Allow Wildcard Checkbox: If the value we want to validate changes dynamically in the target response, then we can use wildcards to validate the response. Suppose, if we consider that the isbn of 1st book always ends with “862“, then we can use the WildCard “*862“, which will validate that the isbn always ends with “862“. It will appear in the Expected Result section as:
-
- Ignore namespace prefix Checkbox: If we want to ignore the namespace prefix while validating the response, we can do that by checking this checkbox.
- Ignore XML Comments Checkbox: if we want to ignore the comments in the response, we can achieve this by selecting this checkbox.
- After exploring all the above options, click on the Save button to save the assertion. It shall pass as the assertion and will get the expected Isbn as “9781449325862“. Consequently, it will show the sample output as follows:
What is XQuery Match Assertionin SoapUI?
The XQuery Match is quite similar to the XPath assertion, with the only difference that it uses an XQuery expression and compare it with the result you expect.
Consider a scenario suppose you want to validate all the “Titles” of the Books available in the response, irrespective of the order in which they exist. You can write a simple XQuery and then you are good to go.
Let’s follow the steps mentioned below to validate the same using “XQuery Match” assertion:
1) First, navigate to the Add Assertion dialogue box. After that, click on the “XQuery Match” assertion under the “Property Content” assertion category, as highlighted below:
2) Secondly, click on the “Add” button, and it will display the “XQuery Match Configuration” dialogue box, as shown below:
Where,
- XQuery Expression: This is the XQuery expression which you need to specify to extract the value from the response of the WebService. For example, to get the Title of all the books, we can specify the XQuery expression as follows:
|
1 2 3 4 5 6 |
<Result> { for$z in //*:CustomBookModel return (<Title>{data($z/*:Title)}</Title>) } </Result> |
In the above code snippet:
-
- <Result> is the tag in which will store the result based on the XQuery response. Moreover, it can be any tag based on user choice.
- Additionally, we are iterating the response using the for loop, and $z is any variable, which will get the value from <CustomBookModel>.
- //.* specifies the root of the CustomBookModel, you can also navigate using Namespace and then specifying the namespace instead of “//.*”.
- In addition to the above, the “return” function will return the value of the <Title> tag.
- Also, the “data” function returns the data of every title tag in the <CustomBookModel> tag.
2) Select from current: Click on the button to select the current value from the response as per the mentioned XQuery.
3) Expected Result: After clicking on the “Select from current” button, it will return all the titles from the response of the service. You can also specify the expected result manually.
4) Clicking on the “Test” button will show the success response, as shown below:
5) Clicking on the “OK” button will show the valid execution of the assertion.
What are the common Compliance, Status, and Standard Assertions in SoapUI?
Like the common assertions provided by SoapUI under the “Property Content” section, it also provides some assertions under the category “Compliance, Status and Standard” assertions, which are common for both SOAP and REST Webservices. Let’s understand the details of all these assertions in the following sections:
What are HTTP Status Codes assertions provided by SoapUI?
As we all know, the HTTP Status Codes represent whether an HTTP request completed or not. All of these response codes generally split into the following categories:
| 1 | 1xx: Informational: These status codes represent the receipt of the request and its processing. |
| 2 | 2xx: Success: These status codes represent that the action was successfully received, processed, and accepted. |
| 3 | 3xx: Redirection: These status codes represent that there is further action that is required to complete the request. |
| 4 | 4xx: Client Error: These status codes represent that the request contains incorrect syntax, or there is something wrong with our request. |
| 5 | 5xx: Server Error: These status codes represent that there is a Server-side error, which means that server failed to fulfill a valid request. |
For validation of these status codes, SoapUI provides a couple of assertions. Let’s understand the details of these assertions in the following sections:
What is a Valid HTTP Status Codes assertion in SoapUI?
This assertion validates that the HTTP response code returned by the Webservice lies in the list of Expected HTTP codes.
Consider a scenario that for the BookStore API, we want to validate that the response code returned is always either 200 or 201. We can use the “Valid HTTP Status Codes” assertion to validate the same.
Let’s follow the steps mentioned below to validate the same using “Valid HTTP Status Codes” assertion:
1) Navigate to Add Assertion dialogue box and click on the “Valid HTTP Status Codes” assertion under the “Compliance, Status and Standard” assertion category, as highlighted below:
2) Click on the “Add” button, and it will display the “Valid HTTP status codes Assertion Configuration” dialogue box, as shown below:
3) In the “Specify codes” section, put values 200, 201. You can specify either a single code or a list of comma-separated codes. Clicking on the “OK” button will validate the HTTP status codes against the last response of the service.
What is an Invalid HTTP Status Codes assertion in SoapUI?
In contrast to the “Valid HTTP status codes” assertion, the “Invalid HTTP status codes” assertion validates that the “Expected codes” list doesn’t contain the HTTP status code returned by the Webservice.
Consider a scenario that for the BookStore API, we want to validate that the response code returned is not 401. We can use the “Invalid HTTP Status Codes” assertion to validate the same.
Let’s follow the steps mentioned below to validate the same using “Invalid HTTP Status Codes” assertion:
1) Navigate to Add Assertion dialogue box and click on the “Invalid HTTP Status Codes” assertion under the “Compliance, Status and Standard” assertion category, as highlighted below:
2) Click on the “Add” button, and it will display the “Invalid HTTP status codes Assertion Configuration” dialogue box, as shown below:
3) In the “Specify codes” section, put values 401. You can specify either a single code or a list of comma-separated codes. Clicking on the “OK” button will validate the non-existence of HTTP status codes against the last response of the service.
Note: We can apply these assertions to both SOAP and REST endpoints.
What are the Schema Compliance assertions in SoapUI?
Apart from status codes, in SoapUI, we can also validate the response message against the definition in the WSDL(SOAP) or WADL(REST) of the target service under test.
Consider a scenario that we want to quickly check whether the SOAP response which we are getting is compliant to the WSDL or not?
Let’s follow the steps mentioned below to validate the same using “Schema Compliance” assertion:
1) Navigate to Add Assertion dialogue box and click on the “Schema Compliance” assertion under the “Compliance, Status and Standard” assertion category, as highlighted below:
2) Click on the “Add” button, and it will display the “Schema Compliance Assertion Configuration” dialogue box, as shown below:
3) In the Configuration dialogue box, it auto-populates the WSDL, which created the project, but if you want to specify some other WSDL, you can also update it. Click OK to proceed.
4) If the response is compliant as per the mentioned schema, you will see the success response, as shown above. You will see the error whenever the last response is not compliant with the WSDL schema.
Note: Similarly, you can validate the response of the REST service against a specified WADL.
What are the common SLA Assertions in SoapUI?
As we all know, a Service Level Agreement(SLA) is generally referred to as the agreement between a service provider and a client. The agreement can be classified by various agreed characteristics such as availability, quality, response time, etc. SoapUI provides the functionality to validate the response time of a specific service.
Consider a hypothetical scenario that the agreed response time for the BookStore WebService is less than 4 seconds. We can validate the same in SoapUI using the “SLA” assertion categories.
Let’s follow the steps mentioned below to validate the same using “Response SLA” assertion:
1) Navigate to Add Assertion dialogue box and click on the “Response SLA” assertion under the “SLA” assertion category, as highlighted below:
2) Click on the “Add” button, and it will display the “Response SLA Assertion configuration” dialogue box, as shown below:
3) Specify the maximum time (in ms), in which the service expects to return the response. For our scenario, we have specified 4000 ms. Click on the OK button to add the assertion. It will show the test result, as shown below:
4) As we can see in the above screenshot, as the response time of the service was 1374 ms, so it was under the mentioned SLA of 4000 ms and resulted in a successful assertion.
Key Takeaways
- SoapUI provides a wide range of assertions that can be applied to both SOAP and REST web services.
- Additionally, few of the common assertions are Contain, Not Contain, Xpath, and XQuery Match, which are used for the validation of the response of the content of the Webservice.
- Moreover, another set of common assertions provided by SoapUI is used for validation of the HTTP Status Codes and the Schema of the response of the WebServices.
- Also, SoapUI also provides an SLA assertion that can be used for validation of the response time of both SOAP and REST services.
Let’s move to the next article where we will deep dive further to understand how we can implement some advance assertions using “Script Assertions” in SoapUI.
