TestComplete samples (both built-in and additional) are located in the <Users>\Public\Public Documents\TestComplete 14 Samples folder.
Some file managers display the Public Documents folder as Documents.
A web service checkpoint is a test operation that verifies that a SOAP response returned from a tested web service contains appropriate data. Verification is done by comparing the actual SOAP response with the baseline copy of the response stored in your project. This helps you to verify that methods of your web service under test work correctly.
|To test web services with TestComplete and call web service checkpoints in your tests, add a Web Service element to your project. The element should correspond to the web service under test. You need to create such elements for each web service under test. For more information, see Testing Web Services - Overview.|
Since the SOAP protocol uses XML for data exchange with web services, the baseline copy of a web service response is stored in your project as the XMLCheckpoint element. To check the actual response against the baseline response, TestComplete uses XML checkpoints.
In keyword test, web service checkpoints are performed using a combination of two operations:
The first Call Object Method operation calls the method of the web service under test. Note that nonscalar parameters (object and arrays) of the method are specified as XMLCheckpoint elements.
The XML Checkpoint operation checks the obtained web service response against the expected response stored in the project.
In scripts, to perform web service checkpoints, the following code is used:
WebServices.WebService1.MyMethod(2, 3, "test", XML.obj);
WebServices.WebService1.MyMethod(2, 3, "test", XML.obj) XML.MyMethodElement.Check(WebServices.WebService1)
Call WebServices.WebService1.MyMethod(2, 3, "test", XML.obj)
WebServices.WebService1.MyMethod(2, 3, 'test', XML.obj);
WebServices["WebService1"]["MyMethod"](2, 3, "test", XML["obj"]);
The first line of the code uses the
WebServices.WebService object to access the web service that will be tested with the corresponding Web Service project element and calls the desired method of the service. Note that nonscalar parameters (objects and arrays) can be specified as XMLCheckpoint elements (for instance,
XML.obj provides scripting access to the obj element of the Stores | XML collection).
WebServices.WebService object stores the response which TestComplete obtains for the last method called. To compare this response with the baseline copy stored in an MyMethodElement element of the Stores | XML collection, the
WebServices.WebService object is passed to the
You can add web service checkpoints to your tests during the test recording and at design time.
TestComplete provides the Web Service Checkpoint wizard that guides you through the process of creating and modifying web service checkpoints. For detailed instructions on using the wizard, see Creating Web Service Checkpoints.
When you create a web service checkpoint, TestComplete calls for the specified web service method, obtains its response and stores it in your project as the XMLCheckpoint element. The stored response will be used as the baseline copy during the verification process.
If your web service contains some variable values, you can modify the generated XMLCheckpoint element to exclude them from verification. For more information on how to do this, see Excluding Variable Data From Verification.
When you run the test, TestComplete first calls the method of the web service under test and obtains the actual response. The WebService scripting object corresponding to the web service under test whose method was called stores the obtained response.
After that TestComplete calls the XML checkpoint that checks the obtained response against the baseline response stored in the specified XMLCheckpoint element and reports the results.
For information on how TestComplete performs the verification of XML data, see How the XML Verification Procedure Works.
If the response obtained from the web service equals the baseline copy stored in your project, the checkpoint posts a success message to the test log.
Otherwise, the checkpoint fails and posts an error message to the test log. The Details panel contains brief verification results. Detailed results are posted to the XML Checkpoint Results panel. The panel displays differences found between the expected and the obtained SOAP responses:
Since actual verification of the obtained response is performed by the XML checkpoint, for a detailed description of the checkpoint results, see Analyzing XML Checkpoint Results.
|Note:||To change the type of the message posted to the test log on verification failure or customize the log message of the checkpoints, use one of the alternative approaches described below.|
TestComplete provides special scripting objects that let you retrieve and work with the contents of SOAP responses of web services under test.
To check the web service response, you can create a custom verification procedure that uses those objects to obtain SOAP response data, parse it and compare response values with baseline values using the
if … then … else statement and comparison operations. For more information on working with web service responses in tests, see Testing Web Services - Overview.
If your web service checkpoint fails because the your tested web service has been modified and now returns response that is different from the baseline response stored in your project, in order for the checkpoint to pass successfully, update the XMLCheckpoint element storing the baseline data with the actual data.
Since the actual web service verification is performed by XML checkpoints, for information on how to update baseline data of your web service checkpoints, see Updating XML Checkpoints.
TestComplete includes a sample project that demonstrates how to perform web service checkpoints:
<TestComplete Samples>\Common\Checkpoints\Web Service
|Note:||If you do not have the sample, download the TestComplete Samples installation package from the support.smartbear.com/downloads/testcomplete/samples/; page of our website and run it.|
These projects work with a sample web service that resides on our web site: