Introduction¶
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).
Solution¶
The following solution is designed using JavaScript and Squish running on a Windows environment. Similar solutions can be developed for other Squish-supported platforms and scripting languages.
To test our solution, we are using a public web service offered by https://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¶
JavaScript does not offer built-in support for handling web services. The XMLHttpRequest object is a JavaScript extension provided by web browsers, therefore we cannot use this object in a test case. One solution is to utilize Socket object, however this would require us to first implement an HTTP protocol to capable of sending a SOAP request over HTTP. Another, and more preferred approach, is to call an external program (using JavaScript OS object) to send the 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.
Both 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¶
So far in our examples we only checked if a SOAP response arrived, but did not verify its content. We can parse the SOAP response using the JavaScript XML Object.
The following code snippet demonstrates how to parse the XML file (above).
First we call
XML.parse(soap_xml)
to obtain adocumentNode
.Then we can traverse the file using the
firstChild
,nextSibling
andtextContent
properties of theXMLNode
object.
Sample Attached¶
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.