Test Coverage for WSDL Generated Apex Code

Integrating third party apps with your Salesforce app can be done easily using the WSDL2Apex tool. We provide to you here the method by which you will not need to modify the generated code but freely update it as desired, adding or removing types or methods in your test class accordingly. The method illustrated here utilizes the UPS Street Address Web Service and requires a small tweak to the WSDL before doing so.

Salesforce.com provides a means to generate Apex classes that allow the calling of a given Web Service as described by a WSDL (Web Service Definition Language). This tool is often referred to as the WSD2Apex tool. Despite not having any real “logic” in them, these classes also need code coverage in order to deploy to Production or include a Package. While the tests for your Apex code that calls the Web Service indirectly ensures you obtain a certain amount of coverage of these classes, it may not be enough. That is because you may only require use of a subset of the types and methods generated. The solution is often to comment out the bits not needed; however this is less than ideal if you plan on regenerating the Apex classes, when the Web Service is updated.

Here are the step-by-step instructions on implementing the said solution –

Step 1

Covering Generated Types. Each of the inner classes generated represents the data types from the WSDL (sometimes these are split into separate Apex classes). While they don’t have any methods in them, they do have static initialization code. Constructing each of these classes will execute this logic and generate coverage.

For each of these in the generated class….

public class wwwUpsComXmlschemaXoltwsCommonV10 {

public class TransactionReferenceType {

public String CustomerContext;

public String TransactionIdentifier;

private String[] CustomerContext_type_info = new String[]{‘CustomerContext’,’http://www.w3.org/2001/XMLSchema’,’string’,’0′,’1′,’false’};

private String[] TransactionIdentifier_type_info = new String[]{‘TransactionIdentifier’,’http://www.w3.org/2001/XMLSchema’,’string’,’0′,’1′,’false’};

private String[] apex_schema_type_info = new String[]{‘http://www.ups.com/XMLSchema/XOLTWS/Common/v1.0′,’true’,’false’};

private String[] field_order_type_info = new String[]{‘CustomerContext’,’TransactionIdentifier’};



Create a test class and test method to cover the type inner classes, repeating the highlightedline of code for each.


private with sharing class wwwUpsComWsdlXoltwsXavV10Test {

private static testMethod void coverTypes() {

new wwwUpsComXmlschemaXoltwsCommonV10.TransactionReferenceType();



Step 2

Covering Generated Methods. Each of the methods on the Port inner class represents the operations described in the WSDL. Fortunately these methods do not care much about the data flowing in or out of them, which makes it easier to create a generic Web Service mock implementation.

For each of these in the generated class methods, observe the types used on the following highlighted section.

public class wwwUpsComWsdlXoltwsXavV10 {

public class XAVPort {

public wwwUpsComXmlschemaXoltwsXavV10.XAVResponse_element ProcessXAV(

wwwUpsComXmlschemaXoltwsCommonV10.RequestType Request,

String RegionalRequestIndicator,

String MaximumCandidateListSize,



wwwUpsComXmlschemaXoltwsXavV10.XAVRequest_element request_x = new wwwUpsComXmlschemaXoltwsXavV10.XAVRequest_element();

wwwUpsComXmlschemaXoltwsXavV10.XAVResponse_element response_x;

// … WSDL2Apex generated code removed for brevity …





Then create the following inner class in your test and repeating the following highlightedline of code.


private with sharing class wwwUpsComWsdlXoltwsXavV10Test {

private class WebServiceMockImpl implements WebServiceMock {

public void doInvoke(

Object stub, Object request, Map<String, Object> response,

String endpoint, String soapAction, String requestName,

String responseNS, String responseName, StringresponseType) {

If (request instance of wwwUpsComXmlschemaXoltwsXavV10.XAVRequest_element)

response.put(‘response_x’, new wwwUpsComXmlschemaXoltwsXavV10.XAVResponse_element());





Create a test method to cover the generated methods, for each of the methods in generated code, repeat the following highlighted line of code for each. Note that you don’t need to worry about the values being provided to the methods, as the Web Service mock does nothing with them at all. Note that the test context still limits the number of callouts to 10 per test method, so you may need to split the method calls across two test methods.


Private with sharing class wwwUpsComWsdlXoltwsXavV10Test {

private static testMethod void coverMethods() {

new wwwUpsComWsdlXoltwsXavV10.XAVPort().ProcessXAV(null, null, null, null);