function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
ForceUser123ForceUser123 

Deploying Apex "Generate From WSDL" Class w/o Unit Tests

Hi,
I'm new to Apex development. 
I used the "Generate From WSDL" option to create an Apex class to access our WebService.
The WebService is fairly large, the generated class came in just under the limit at 95k characters.
When I went to deploy this class from my Sandbox to our production environment (using Apache Ant),
I received an error saying 0% of my class was covered by Unit Tests.
Now, I wrote a test, but it gave a warning saying:
"Testmethods do not support webservice callouts".
So essentially Unit Tests for this class are just fillers to get past the 75% restriction.
At 95k characters, I'm looking at a lot of empty Unit Tests to get this code deployed on our production environment.
Is there currently any way to deploy an auto-generated apex class w/o writing Unit Tests?
Thanks in advance.
Best Answer chosen by Admin (Salesforce Developers) 
cheenathcheenath
Unfortunately there is no way to remove the 75% code
coverage restriction for generated package.
Do you use all methods/types defined in the WSDL.
If not, it may be a good idea to trim the WSDL before generating apex.

All Answers

cheenathcheenath
Unfortunately there is no way to remove the 75% code
coverage restriction for generated package.
Do you use all methods/types defined in the WSDL.
If not, it may be a good idea to trim the WSDL before generating apex.


This was selected as the best answer
ForceUser123ForceUser123
That'll work.  Not the best solution, but better than writing 700+ unit tests :D
Thanks.
gitguygitguy

Is there a way to dislike an answer even when it's the best answer?  

 

Your answer is correct as far as I know, but it's still disappointing.
hemantgarghemantgarg
is there any way to cover the generated class code ?
tggagnetggagne

We've stooped pretty low to compensate for this.  

 

We created a class that looks something like this.

 

public class CompensateForWebServiceCallsTest {
	static testMethod void giveMeCodeCoverage(){
		string x;
		x = lotsOCode();
		
		system.assertNotEquals(0, x.length());
	}

	static string lotsOCode(){
		string thisIsEmbarassing = '';

		thisIsEmbarassing += 'a';
		thisIsEmbarassing += 'b';
		thisIsEmbarassing += 'c';
		thisIsEmbarassing += 'd';
		thisIsEmbarassing += 'e';
// repeated 2900 times...
		thisIsEmbarassing += 'u';
		thisIsEmbarassing += 'v';
		thisIsEmbarassing += 'w';
		thisIsEmbarassing += 'x';
		thisIsEmbarassing += 'y';
		thisIsEmbarassing += 'z';
		
		return thisIsEmbarassing;
	}
}

 The HUGE drawback of this approach is it inflates the total lines of Apex in your box.  In some situations, organizations can't afford that kind of code bloat.
tggagnetggagne

Yesterday we discovered something HUGE to help this.

 

Most of our partner's WSDLs create classes that are all data and no (important: no) code.  These classes have THOUSANDS of lines of data.  There's no-way to cover these classes in code because class definitions are never executed no matter how often you instantiate them and use their properties.

 

However, simply adding @isTest to the top of those classes removes those definitions from the official line count, meaning they don't have to be covered with unit tests.

 

We were able to remove the Compensate* classes.  Our percent of Apex code used droped to 33% from 78%, and our code coverage rose from 74% to 88%.

 

SOLVED!