Generating a Web Service Consumer Unit Test Class and Stub Methods

You can generate a set of stub methods that can be used for Web service consumer unit testing. If the schema is versioned and you are working in the latest version, the existing JadeTestCase subclass is versioned if it is unversioned.

In the description in this section, the WSD_ErewhonInvestmentsService sample Web service consumer is used, which exposes the methods shown in the following image.

To generate stub methods for your Web service consumer

  1. Select the Generate Web Consumer 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 JadeWebServiceConsumer class.)

    The Generate Test Case dialog, shown in the following image, is then displayed.

  2. In the Test Name text box, change the unit test class, if required. The name of the JadeTestCase subclass that is created defaults to the Web service consumer subclass name (WSD_ErewhonInvestmentsService, in the example in this section) with the Test_ prefix. The Generate Test Case dialog lists all methods in the JadeWebServiceConsumer subclass that have the webService method option defined.

  3. 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.)

  4. Check the Generate Parameter Defaults check box if you want to generate stub code for the method parameters.

  5. 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.

  6. Check the Generate Expected Defaults check box if you want to generate stub code for the expected return value.

  7. 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_WSD_ErewhonInvestmentsService and all of the check boxes have been checked.

When you are generating a test case for the same JadeWebServiceConsumer subclass into an existing JadeTestCase class, the generate process:

When you click the OK button, the JadeTestCase subclass, shown in the following image, is then generated.

In addition to the stub methods generated for each of the methods defined in the Web service, a create method and a wSD_ErewhonInvestmentsService property that references the Web service are also generated.

The value of the wSD_ErewhonInvestmentsService property is initialized in the create method to the Web service from which the test was generated.

The code that was generated for the getClient method is shown in the following image.

In this code:

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 the above example to run the method results in a failed assert. The method test fails because the expected value does not match the return value.

Running a test when there is a web service fault such as an HTTP error results in the test failing with an unexpected error, as shown in the following image.

If an assert advises you that the correctness of a test method requires verification, that assert always fails.

When the test has been coded correctly, the assert should be removed. For example, if you want the test to check that the name property in the Client object returned by the Web service is the same as the requested name, the following image shows the required method modifications.

Note that the last assert has been removed and that client name Sidney has been set up. The result of running this modified test is that the test has a status of passed, highlighted with a green background, and the test in the Select Tests pane at the left of the Unit Test Runner form displays a check mark symbol.

Similarly, you can set up other expected values and compare these to the return values.

For details about the Unit Test Runner form, see the "Using the Unit Test Runner Form", 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.