Modern and complex web applications often offer two interfaces: one for humans (GUI) and one for other computers/systems (Web Services Interface).
While Squish is primarily a GUI testing tool, even for some GUI testing scenarios sending a request to a web service may be needed.
Web services can provision test data for a GUI test by changing or verifying a web application state (if not possible via the GUI). For long and complex test scenarios, sending a web service request may also speed-up the total test execution time.
For example, if a pre-condition for every GUI test is to create a specific user for that test, but creating such user is not a goal of our GUI test, then we can create those users using the Web Service Interface (assuming the web application offers such functionality).
To test our solution, we are using a public web service offered by http://www.webservicex.net (note: dead link). We will send a SOAP 1.2 web service request via the HTTP POST method to www.webservicex.com/globalweather.asmx with the GetCitiesByCountry SOAP action. As a result we will get a response with the list of airports for given country.
Sending a SOAP Request¶
We developed a simple VBScript for the Windows platform which utilizes the Msxml2.XMLHTTP object to send the SOAP Request. This program can be called from command line:
Where <SOAP_REQUEST_FILE> is an XML file with SOAP request and <SOAP_RESPONSE_FILE> is a filename, where the response from a web service shall be written.
Next we need to create a function to call in a test case which sends the SOAP request. The function requires two arguments: (a) the filename containing the SOAP Request and (b) a filename where the SOAP response shall be written. All web service parameters will be fetched from an external test configuration file
ws_params.js containing the necessary parpameters to send the SOAP request to our test web service.
Since the web service parameters are in an external test configuration file, we can use the Squish findFile function. If the same request is used across multiple test cases, then we can store
ws_params.js in our Test Suite Recourses, otherwise we can store it in the Test Case Resources, available only to the applicable test case.
MS_HTTPXML.vbs script and soap function need to be placed in the Global Scripts directory, making it accessible to all Test Cases within all Test Suites.
Simple Test Case¶
First, we need to prepare a SOAP Request to be sent (file
SOAP_request.xml) and place it in the Test Case Resources (Test Data).
Below is a simple test case which sends the SOAP request (above). After which we call a waifFor function to wait 30 seconds for the SOAP response to arrive.
Making the Test Case Data Driven¶
In the above example we store the SOAP request in the Test Case Resources using a hardcoded country name
<ns1:CountryName xmlns:ns1='http://www.webserviceX.NET'>Poland</ns1:CountryName>. This solution is sufficient if we only have a few test cases sending requests to a web service. For more extensive use a more robust solution is recommended.
*First, we would like to avoid fixing multiple test cases when a SOAP request format changes.
*Second, we would like to make our test case data driven, therefore we should separate the SOAP request itself from the test data ("Poland").
Preparing a SOAP Request Template¶
We can achieve both by preparing a SOAP request template and storing it in the Test Suite Resources (Test Data). The request contains a
CountryName place holder which is filled with the test case provided country name before sending the SOAP request.
Creating a Test Data Resource¶
Next create a new test data resource with only one column CountryName.
Sending Multiple SOAP Requests¶
Finally we can create a test case which sends multiple SOAP requests depending on entries in the test data table as demonstrated in the code snippet below. The code snippet iterates over all table entries in the test data and replaces
CountryName with the country name value from the table. After the test case executes, all sent and received SOAP requests are stored in Test Case Recourses for further analysis.
Parsing A SOAP Response¶
The following code snippet demonstrates how to parse the XML file (above).
First we call
XML.parse(soap_xml)to obtain a
Then we can traverse the file using the
textContentproperties of the
A Test Suite containing the example test cases, global script directory and necessary scripts and functions used in Test Suite is attached to this article.