Creating Web Service Tests

Applies to TestComplete 15.62, last modified on March 19, 2024
Testing web services with TestComplete is obsolete. We recommend that you use ReadyAPI, another SmartBear's automated testing tool for SOAP and REST web services.
If needed, you can run ReadyAPI tests from TestComplete.

Functional testing of web services consists in calling web service methods from test scripts or keyword tests and checking the result values. This topic provides step-by-step description of this process.

1. Planning a Test

Before creating script code or a keyword test, plan your web service test:

  1. Define the test goal and decide which service functionality should be tested.

  2. Define the methods to be called, the call order and how you will check the method result. You may need to ask the service developer about the call order and the methods’ result values. To explore the service’s methods, expand the Methods node in the WebService editor (see below).

  3. Define how you will store the input data and the baseline values for the result comparison. For instance, a storage can be a text or an xml file, an Excel sheet, database tables or a script array. To check the result you can also create a web service checkpoint (see Using Web Service Checkpoints in About Testing Web Services).

After you planned the test, start creating it.

2. Adding a Project Item to Your Web Service Project

To perform functional testing of a web service, add the Web Services project item to your project and add a child element for your service to this item:

  1. Open your project in TestComplete.

  2. Right-click the project’s node in the Project Explorer panel and select Add > New Item from the context menu. This will open the Create Project Item dialog.

  3. Use this dialog to add the Web Services item to your project. The added item will be displayed in the Project Explorer.

  4. Right-click the WebServices node in the Project Explorer and choose Add > New Item from the context menu.

  5. Use the subsequent dialog to add a child Web Service element to the Web Services project item.

After adding the Web Service element to your project, you can specify its properties.

3. Selecting a Toolkit for Web Service Testing

To control the API used to call methods of the web service under test, use the Preferred Web Service API set of options. If the .NET WCF option is selected, TestComplete uses the .NET API to call methods of the web service under test. Otherwise, the native API is used.

By default, TestComplete uses the .NET API. However, you can easily change the API by enabling or disabling the above-mentioned options. For example, you can use this option to handle situations when the tested web service provokes errors when you access its methods from your tests. That is, when an error occurs, change the API and try to test the web service again.

4. Specifying the Web Service for Testing

You specify the web service to be tested in the WebService editor. To open the editor, right-click the web service element in the Project Explorer panel and select Edit from the context menu. TestComplete will open the WebService editor in the Workspace panel (note that TestComplete automatically opens the editor right after you added the web service item to your project).

In the editor, click Select. This will call the Select Web Service dialog, in which you can specify the WSDL document of the desired web service and specify the service for testing.

Note: If your computer connects to the tested web service via proxy, then you may need to specify the address, port of the proxy web server and the user name and password used for connection in the Web Services Options dialog.

If you are not sure whether your computer works via proxy or not, ask you system administrator.

When parsing the specified WSDL document, TestComplete automatically creates the auxiliary item0.wsdata file that stores the corresponding WSDL document and all of the linked schemes. This file is used by TestComplete and required for testing of the corresponding web service. If the initial web service contained several WSDL documents, TestComplete will create several files with the following names: item0.wsdata, item1.wsdata, and so on.

5. Exploring Web Service’s Methods and Objects

Methods and objects provided by the web service are displayed as a tree-like structure in the WebService editor.

Information about methods is shown under the Methods node of the tree. Information about the object types described in the service’s WSDL document is shown under the Types node.

The syntax of the selected method is displayed at the bottom of the page. To form the syntax string, TestComplete uses the scripting language of the project, to which the web service item belongs. The syntax section is automatically hidden when you select a node of the Types section.

Both methods’ parameters and objects’ properties can be arrays or they can refer to objects. If a parameter (or property) refers to an object, the Data Type cell displays the name of this object.

For the parameters and properties that are arrays, the editor shows parentheses or brackets next to the name in the Data Type column. The symbols to be used depend on the scripting language of your TestComplete project. For instance, the editor uses parentheses for VBScript projects and brackets for JScript projects.

To explore the object, to which a parameter or property refers, select this parameter or property in the tree and then click Go to Definition in the Data Type cell.

If a method uses parameters that refer to an object, then, to call this method, you should write script code that creates the appropriate object. You can either write this code from scratch, or generate it automatically. To generate the code, select the desired object under the Types node and then click Code in the Data Type cell. TestComplete will generate the appropriate script code and display it in the Generated Code dialog. You can then copy this code in the dialog and paste the code in your script unit.

6. Preparing Data for Testing

To test methods thoroughly, you will need to call them several times and feed different input parameters for each call. Of course, you can hard code each call and the parameters in your script or keyword test, but a better approach is to call a method (or methods) in a loop and supply different input parameters for method calls on each iteration.

You can define and store input data to a storage and then read the data from this storage on each iteration. A storage can be a text or XML file, an Excel sheet, a database table or a script array. For instance, you can store data in a comma separated value (CSV) file and read input parameters from this file line by line on each iteration. The baseline values that will be used to check the method results can be stored along with input data.

For more information on how to read data from CSV files and other storage types, see the following topics:

7. Calling Service’s Methods and Checking Results

To work with web services from scripts and keyword tests, use the WebServices object. The object provides a scripting interface to all web service project elements displayed in the Project Explorer panel.

Calling a service’s method is a matter of a single script line (you can execute this from your keyword test using the Run Code Snippet keyword test operation):

JavaScript, JScript

resultValue = WebServices.WebService1.MyMethod();

Python

resultValue = WebServices.WebService1.MyMethod()

VBScript

resultValue = WebServices.WebService1.MyMethod

DelphiScript

var
  resultValue : OleVariant;
begin
  resultValue := WebServices.WebService1.MyMethod;
end;

C++Script, C#Script

resultValue = WebServices["WebService1"]["MyMethod"]();

In this example, WebService1 is the name of the web service element in the Project Explorer panel and MyMethod is the name of the tested method.

Note: A call to a web service’s method may take time, especially if the Internet connection is slow or if it is broken. Using the Web Services Options dialog you can control the timeout values used to detect and close inactive connections (that is, TestComplete will close these connections and your test will not “hang”).

You specify the parameters of a web service method the same way you specify parameters for ordinary script functions:

JavaScript, JScript

resultValue = WebServices.WebService1.MyMethod("StringParameter", 123, true);

Python

resultValue = WebServices.WebService1.MyMethod("StringParameter", 123, True)

VBScript

resultValue = WebServices.WebService1.MyMethod("StringParameter", 123, True)

DelphiScript

var
  resultValue : OleVariant;
begin
  resultValue := WebServices.WebService1.MyMethod('StringParameter', 123, true);
end;

C++Script, C#Script

resultValue = WebServices["WebService1"]["MyMethod"]("StringParameter", 123, true);

To create objects that are needed for a method call, use the TypeFactory property which TestComplete adds to all WebService program objects. After the object is created, you can specify its properties and pass the object to the method:

JavaScript, JScript

var MyObj, resultValue;

// Creating the object
MyObj = WebServices.WebService1.TypeFactory.MyObject;
MyObj.Property1 = "Value1";
MyObj.Property2 = 2;
MyObj.Property3 = true;

// Calling the method
resultValue = WebServices.WebService1.MyMethod(MyObj, "Param2", 123, true);

Python

# Creating the object
MyObj = WebServices.WebService1.TypeFactory.MyObject
MyObj.Property1 = "Value1"
MyObj.Property2 = 2
MyObj.Property3 = True

# Calling the method
resultValue = WebServices.WebService1.MyMethod(MyObj, "Param2", 123, True)

VBScript

' Creating the object
Set MyObj = WebServices.WebService1.TypeFactory.MyObject
MyObj.Property1 = "Value1"
MyObj.Property2 = 2
MyObj.Property3 = True

' Calling the method
resultValue = WebServices.WebService1.MyMethod(MyObj, "Param2", 123, True)

DelphiScript

var
  MyObj, resultValue : OleVariant;
begin
  // Creating the object
  MyObj := WebServices.WebService1.TypeFactory.MyObject;
  MyObj.Property1 := 'Value1';
  MyObj.Property2 := 2;
  MyObj.Property3 := true;

  // Calling the method
  resultValue := WebServices.WebService1.MyMethod(MyObj, 'Param2', 123, true);
end;

C++Script, C#Script

var MyObj, resultValue;

// Creating the object
MyObj = WebServices["WebService1"]["TypeFactory"]["MyObject"];
MyObj["Property1"] = "Value1";
MyObj["Property2"] = 2;
MyObj["Property3"] = true;

// Calling the method
resultValue = WebServices["WebService1"]["MyMethod"](MyObj, "Param2", 123, true);

You can use the WebService Test editor to automatically generate script code that will be used for creating objects. For detailed information on this, see above.

Note: If the object’s property name is not a valid script identifier, TestComplete will skip invalid characters to make it possible for you to work with the property from scripts or keyword tests. For instance, if an object contains the property My-Prop, TestComplete will skip the hyphen and use the name MyProp. If the object already contains the property MyProp, then the My-Prop property name will be changed to MyProp1 (and so on).

An alternative approach to creating objects or array parameters to be used in a method call is using XMLCheckpoint elements of the Stores | XML project collection. These elements store XML documents to be used in testing. So, these documents can store the same XML data that is used in SOAP requests to transfer data of objects and arrays (web services use the SOAP protocol that transmits data using the XML format).

This way of creating object and array parameters is typically used by web service checkpoints and by the Web Service Checkpoint keyword test operation. However, you can also use this approach. The whole procedure includes the following steps:

  1. Add the Stores project item to your project (for more information on how to do this, see Adding and Removing Project Items and Their Child Elements).

  2. Add a new XMLCheckpoint element to the XML collection of the Stores project item (for more information on how to do this, see Adding and Removing Project Items and Their Child Elements).

  3. Right-click the added XMLCheckpoint element in the Project Explorer and choose Edit from the context menu. This will open the XMLCheckpoint Element editor in the Workspace panel.

  4. In the editor, specify the XML document that corresponds to the fragment of the SOAP request used to transfer the object or array. See the editor description.

  5. Save the changes.

  6. Pass the created XMLCheckpoint to the desired method in scripts or in keyword test operations:

    JavaScript, JScript

    var resultValue;

    // Calling the method
    resultValue = WebServices.WebService1.MyMethod(XML.MyObjElement, "Param2", 123, true);

    Python

    # Calling the method
    resultValue = WebServices.WebService1.MyMethod(XML.MyObjElement, "Param2", 123, True)

    VBScript

    ' Calling the method
    resultValue = WebServices.WebService1.MyMethod(XML.MyObjElement, "Param2", 123, True)

    DelphiScript

    var
      resultValue : OleVariant;
    begin
      // Calling the method
      resultValue := WebServices.WebService1.MyMethod(XML.MyObjElement, 'Param2', 123, true);
    end;

    C++Script, C#Script

    var resultValue;

    // Calling the method
    resultValue = WebServices["WebService1"]["MyMethod"](XML["MyObjElement"], "Param2", 123, true);

    MyObjElement is the name of the XMLCheckpoint element of the Stores | XML collection.

After calling the service method, you have to check its result and decide whether the method call was successful or not. To perform the check, use comparison statements such as If... Then, switch... case or Select Case, for example:

JavaScript, JScript

resultValue = WebServices.WebService1.TestSumMethod(2, 3);
if (resultValue != 5)
  Log.Error("Error");
else
  Log.Message("OK");

Python

resultValue = WebServices.WebService1.TestSumMethod(2, 3)
if (resultValue != 5):
  Log.Error("Error")
else:
  Log.Message("OK")

VBScript

resultValue = WebServices.WebService1.TestSumMethod(2, 3)
If resultValue <> 5 Then
  Call Log.Error("Error")
Else
  Log.Message("OK")
End If

DelphiScript

var
  resultValue : OleVariant;
begin
  resultValue := WebServices.WebService1.TestSumMethod(2, 3);   
if resultValue <> 5 then
    Log.Error('Error')
  else
    Log.Message('OK');
end;

C++Script, C#Script

resultValue = WebServices["WebService1"]["TestSumMethod"](2, 3);
if (resultValue != 5)
  Log["Error"]("Error");
else
  Log["Message"]("OK");

If you are going to use a lot of data for testing, you can store them in a CSV file or in an Excel sheet. To read data from these sources, you can use the data-driven testing means provided by TestComplete (see Data-Driven Testing). Baseline values that will be used to check the results can be stored along with the test data.

Sample

TestComplete includes a sample project that demonstrates how to call web service methods from scripts, prepare complex parameters for the methods to be called and check the returned results by using script statements and checkpoints:

<TestComplete Samples>\Common\Web Service Testing\Functional Testing

Note: If you do not have the sample, download the TestComplete Samples package from the https://support.smartbear.com/testcomplete/downloads/samples/ page of our web site and run it.

These projects work with a sample web service that resides on our web site:

secure.smartbearsoftware.com/samples/testcomplete15/webservices/Service.asmx

See Also

About Testing Web Services
Calling Web Service Methods That Use Out Parameters
Creating Objects and Arrays for Web Service Method Calls
WCF Services - Specifics of Testing
Prepare SOAP Requests in Scripts
About Web Service Checkpoints
Web Service Checkpoint Operation
About Testing Web Services

Highlight search results