Creating Web Service Tests

1. Planning a Test

2. Adding a Project Item to Your Web Service Project

3. Selecting a Toolkit for Web Service Testing

4. Specifying the Web Service for Testing

5. Exploring Web Service’s Methods and Objects

6. Preparing Data for Testing

7. Calling Service’s Methods and Checking Results

Sample

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 Testing Web Services - Overview).

After you planned the test, start creating it.

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.

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.

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.

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.

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.

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:

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):

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.

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

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:

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.

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

   Python

   VBScript

   DelphiScript

   C++Script, C#Script

   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:

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.

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

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

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