You can generate a set of stub methods that can be used for Web service consumer unit testing.
In the description in this section, the sample Web service that is used is called CustomerService, which exposes the three methods shown in the following diagram.
To generate stub methods for your Web service consumer
Select the Generate Test Case command from the Classes menu in the Class Browser.
This command is enabled only when the selected class is a subclass of the
The Generate Test Case dialog, shown in the following diagram, is then displayed.
In the Test Name text box, change the unit test class, if required. The name of the
The Generate Test Case dialog lists all methods in the
In the table of methods defined in the Web service consumer subclass, check the check box in the Select column of each method for which you want a test case generated.
Conversely, if you want to select all of the methods, check the Select All Methods check box. (Unchecking this check box does not affect the list of selected methods.)
Check the Generate Parameter Defaults check box if you want to generate stub code for the method parameters.
Check the Assert all tests as Incomplete check box if you want to add an assert to the method code to say that the test is not complete.
Check the Generate Expected Defaults check box if you want to generate stub code for the expected return value.
Click the OK button. Alternatively, click the Cancel button to abandon your selections.
If you click the OK button and you have not selected any methods, No methods were selected - Continue? is displayed in a message box. Click No if you want to cancel the process and return to the dialog or click Yes to continue with the generate process.
For the example in this section, the name of the test has been left as Test_CustomerService and all of the check boxes have been checked.
When the OK button is clicked, the
In addition to the stub methods for each of the methods defined in the Web service, a create method and a customerService property that references the Web service are also generated.
The value of the customerService property is initialized in the create method to the Web service from which the test was generated.
The code that was generated for the getCustomer method is shown in the following diagram.
In this code:
Lines 12 through 20 represent the expected defaults and are generated when the Generate Expected Defaults check box is checked.
Lines 23 and 24 represent the parameter default values that are generated when the Generate Parameter Defaults check box is checked.
Line 27 is the call to the Web service.
Lines 29 and 30 are the default asserts. Line 30 is generated when the Assert all tests as Incomplete check box is checked.
This assert serves only as a reminder to you that the method needs to be changed.
As this is a stub method only, running this test without any modifications is not likely to work; for example, pressing F9 on the method in this example to run the test results in the failed results shown in the following diagram.
The first assert fails because the expected value does not match the return value.
The second assert always fails. When the test has been coded correctly, this assert should be removed. For example, if you want this test to check that the customerNumber property in the Customer object returned by the Web service is the same as the requested number, the following diagram shows the required method modifications.
Note that the last assert has been removed and that customer number 100 has been set up. The result of running this modified test is shown in the following diagram.
Similarly, you can set up other expected values and compare these to the return values.
For details about the Unit Test Runner dialog, see the "Using the Unit Test Runner Dialog", later in this chapter.
It makes sense to compare primitive type values only, as returned object instances will not match because they will always be different (transient) object instances.
