Once a request is sent to a web server a response is received. We need to validate if the response contains the data that we expect. In order to validate the response, we need to use assertions.
Types of Assertion
There are various ways of asserting a response; however, we will focus on the commonly used SoapUI Assertions types while validating a response. Below are the ones that are available in Open Source version of SoapUI.
Property Content Compliance Status Standard Script SLA JMS Security
Apart from the ones that are listed above, PRO version also has an inbuilt JDBC Assertion using which we can assert if the web service has updated the database correctly. In this tutorial we will study
Contains Assertion Not contains Assertion X Path Match Assertion. Scripting Assertion X Query Match Assertion
CONTAINS ASSERTION
Searches for the existence of the specified string. It also supports regular expression. We will continue with the same example from the previous tutorial with WSDL request as http://www.dneonline.com/calculator.asmx. Step 1: By Default there are no assertions.
The Number of Assertions are shown in the Assertions Tab. To add a new assertion, click on ‘Add New Assertion’ button.
Step 2: Now,
Select the Assertion Category. Select the Assertion Type. Click ‘Add’
Step 3: Let us validate if the string ’46’ exist in the response. Click ‘OK’ Note: We can also ignore case and add regular expression.
Step 4: Upon adding it, immediately assertion is executed and shows if VALID or INVALID.
Step 5: Now Let us say we change the content of ‘Contains Assertion in SoapUI’ to ’47’ and see what happens.
Step 6: The Assertion is executed and the result is thrown to the user. Since we don’t have the string ’47’ within the response, the assertion has failed.
NOT CONTAINS ASSERTION
Searches for the Non-existence of the specified string. It also supports regular expression. Step 1: Now after clicking on ‘add new assertions’ button,
Select the Assertion Category. Select the Assertion Type – In this case ‘NOT Contains’ Click ‘Add’
Step 2: Let us validate if the string ‘intA’ exist in the response. Enter the string ‘FromCurrency’ and Click ‘OK’
Step 3: As soon as an assertion is added, it executes and displays the result. So far we have added two assertions hence both the assertions are executed and displayed the result.
Step 4: 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 “AddResult”.
Step 5 : The string ‘AddResult’ is actually present in the response, hence the ‘NOT Contains’ assertion will fail as shown below.
XPATH MATCH ASSERTION
Uses XPath expression to select the target node and its values. XPath, is an XML query language for selecting nodes from an XML document. Step 1: Now after clicking on ‘Add New Assertions’ button,
Select the Assertion Category. Select the Assertion Type – In this case ‘XPath Match’ Click ‘Add’
Step 2: Add XPath Window opens. Before Adding SoapUI XPath, we need to declare the NameSpace. An XML namespace is a collection of names, identified by a Uniform Resource Identifier (URI) reference, which are used in XML documents as element and attribute names. The same is used in SOAP UI XPath Assertion. For declaring XML Namespace, we just need to click on ‘Declare’ button which would do the job for us else we can also manually declare a namespace ourselves. After declaring the namespace we need to refer the XPath using the created name space. Upon clicking the ‘Declare’ button, two namespaces will pop up as we have two URI’s. One of them is the schema URL and the other one corresponds to the actual web service URL. We need to use the actual namespace where the web service is located and NOT the schema namespace while referencing XPath.
declare namespace soap=’http://schemas.xmlsoap.org/soap/envelope/’; declare namespace ns1=’http://tempuri.org/’;
Step 3: Now we need to enter the XPath of the XML node that we need to validate.
//ns1:AddResult Gives us the Value of the node enclosed between
Step 4: So far,
After declaring the namespaces, we have entered the XPath of XML node that we need to Validate. We Need to click ‘Select from Current’ to make the current value as the expected value. The current value is shown to the user which we can modify if required. Click ‘Save’.
Step 5: The added Assertion in SoapUI will be displayed as shown below.
Scripting Assertions
This Assertion technique is the most widely used one as it is extremely difficult to manage and maintain hundreds of assertions. SOAP UI uses either Groovy Scripting or JavaScript for scripting assertions. The scripting technique is adopted for developing a framework for testing SOAP. Scripting assertions are used under following circumstances. Scripting allows user to perform some operations before and after executing a TestCase using set up and tear down methods respectively. Set up is a procedure which is executed before executing a particular method(example – Object creation and Initialization) while tear down is a procedure which is executed after executing the method(eg: Destroying objects and clean up). This feature is not available in other Assertion types and can be done only through coding. It allows users to perform opening/closing a Project, inorder to initialize or clean-up Project related settings and also to work with environmental variables which is very helpful during scripting. It helps us in asserting a dynamic Response content. Scripting assertions are used for creating user defined assertions that are NOT predefined by SOAP UI. For Demonstrating Script assertion in SoapUI, we will make use of calculator WSDL, the test case ‘Add’ that we had created earlier. Step 1: Steps to add groovy script is same as that of other assertions except that the assertion is not a predefined one. Instead it is a user defined assertion which offers greater flexibilities than the inbuilt ones. Select the Test step against which the assertion has to be added.
Click ‘Add Assertion’ Button as shown below.
Step 2: Now select the Assertion category.
In this case it is Script. Select SoapUI Script Assertion and there no sub-types associated with it. Click ‘Add’.
Step 3: The Scripting Dialog opens where user will be able to write user defined script to validate the response XML.
Step 4: Now let us write a groovy script to validate the Conversion Rate. The Script is attached below with the comments embedded. It is recommended to have knowledge on Java Script or Groovy Script before attempting to write your own script.
Click ‘Execute’ Button to trigger the execution. The output of the Script is shown in the Output pane. It has printed both, Conversion Value as well as the end result (Pass or Fail) The Information is displayed that ‘Script Assertion Passed’. Click OK.
Note: The final Information pop up will always display with the message ‘Script Assertion Passed’ as long as the script is syntactically correct. It has got no correlation with your assertion within the script.
Click OK Step 5: Now the assertion Tab displays all the assertions that we had added for this test suite with the Status against each one of those.
Step 6: Now
Select the Test Suite from the Navigator tree Click ‘Run’ Button Results would be displayed for the entire test suite.
Xquery Match Assertion
It Uses an Xquery expression to select content from the target property. We need a much bigger response XML in order to better understand XQuery assertion in SoapUI. Let us import one other WSDL as shown below: http://www.webservicex.net/medicareSupplier.asmx?WSDL Step 1: Perform a Right click on the existing project and select ‘Add WSDL’.
Step 2: Perform a Right click on the existing project and select ‘Add WSDL’. Leave other options as default and Click ‘OK’ Button.
Step 3: All the operations are listed as shown below.
Step 4: Now let us add a Test Case within the same test suite that we had created for Testing the currency converter.
Step 5: Enter the name of the test case and Click ‘OK’ Button
Step 6: The test case is created as shown below.
Step 7: Add a new test step of Type ‘Soap Test Request’ as shown below.
Step 8: Enter the name of the test step. Let us say – Supplier_by_City which would be more meaningful Click ‘OK’.
Step 9: Select the Operation that we would like to validate. In this case it is ‘MedicareSupplierSoap -> GetSupplierByCity’. Click ‘OK’.
Step 10: Enter the Name of the test case and click ‘OK’.
Step 11: The Request XML Outline would be displayed as shown below.
Step 12: Now let us find all supplier information for the ‘New York’ City. To do so, add the following lines to your code. WSDL in the below URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity
Step 13: Upon executing the test, we receive the below response
Step 14: Let us say we need to Validate all the Supplier Number. We can’t use XPath Assertion as we need to have hundreds of XPath Assertion. Hence the usage of XQuery is inevitable in this case. XQuery Assertion helps us to validate a group of XML response which are repetitive in nature.
Step 15: Now click on ‘Add an assertion’,
Select the ‘Assertion Category’ – Property Content in this case. Select the Assertion Type as ‘XQuery Assertion’ Click ‘Add’.
Step 16: Similar to XPath Assertion we need to declare the namespace.
Click ‘Declare’ Button to automatically allow SOAP UI to declare the namespace. Upon clicking on declare button a ‘POP up’ with the message ‘declare namespace from schema instead’ will be displayed to the user. Click ‘Yes’ to proceed as shown below. Note: Upon hitting ‘Declare button’ you might end up with different URL’s as namespace declaration, however, the actual web service location namespace is what would be considered for coding.
For retrieving all the Supplier Number, We need to write an XPath Query and we will place it within < SupplierNumber> and </ SupplierNumber> Tags. Click ‘Select from the Current’ which will execute from the current response. Upon Clicking ‘Select from the Current’, All the Supplier Number are listed. Click ‘Save’.
Step 17: XQuery Assertion is executed and displays the final result in the ‘Assertion’ Panel as shown below. Now we have successfully added an Xquery assertion using which we have validated all the supplier Number information. The same would be compared against the actuals, every time the request is sent to the webserver. Note: The actual values won’t be displayed. If all actual values are same as that of the expected values, then it displays VALID else it will display ‘Failed’.
When To Use Inbuilt Assertion?
When a Response is short such that it can be validated using one of those inbuilt assertions. We can also use Inbuilt Assertion if the response sent from the web server is always static in nature. If it is dynamic, we will not be able to assert it using inbuilt assertions. When usage of inbuilt assertions such as Time out assertions and security assertions becomes inevitable. Inbuilt Assertions holds good pretty well for one-time usage where tests need not be repeated.
Assertions Options
The created assertions can be best controlled with the help of control panel that is highlighted below.
The created assertions allow testers to configure following things from the assertions toolbox.
Below are the features available exclusively in PRO Version of SOAP UI. PRO version also helps us to Group assertions so that we can add one more layer of validation to the created assertions. AND: All assertions are evaluated as VALID assertion which will result in PASSED group condition.OR: At least one of the assertions within the group must be VALID in order to assert a group PASSED condition. Pro Version also allows Cloning of Assertions: This option lets testers to allow copying an assertion to a different test step in the same or a different project. Disable/Enable Assertions: This option allows any grouped or ungrouped assertion to be disabled or enabled. If an assertion is disabled, it is grayed out and when a Test Case is executed, disabled assertions won’t be executed. Ungroup Assertions: Any grouped assertions can be ungrouped if testers decide to do so.
Complete List of Methods available in various assertion types
DOWNLOAD THE SOAPUI PROJECT CONTAINING ABOVE ASSERTIONS
Pro Version also allows Cloning of Assertions: This option lets testers to allow copying an assertion to a different test step in the same or a different project.
Disable/Enable Assertions: This option allows any grouped or ungrouped assertion to be disabled or enabled. If an assertion is disabled, it is grayed out and when a Test Case is executed, disabled assertions won’t be executed.
Ungroup Assertions: Any grouped assertions can be ungrouped if testers decide to do so.
Common Errors and Trouble Shooting
Use the correct namespace. The Name space should be the URL where the web service is located. If an error thrown while developing a scripting assertion, use ‘log.info’ to print the contents of the variables If you haven’t got the desired output, verify if a valid input is passed in the request. For example, in currency converter, if you input the ‘intA’ as ‘x’ which is not integer, the output throws a fault code as ‘SOAP-Client’ which means that the issue is with the parameter that is being passed from the client side.
Ensure that you use the correct syntax while using XPATH and XQuery assertion. You should NOT use dot(.) instead of colon(:) while using the above assertion. The Syntax is //namespace:Tagname and NOT //namespace.tagname. By doing so, you might end up having a message that ‘NO match in current response’ even though the tag name is correct.
