function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
opiedogopiedog 

Apex test coverage issues

I've lost hours trying to work around what must be bugs with the force IDE and how it calculates test coverage. Before I keep trying to hack around what seems like a very fragile system, I thought I'd get a reality check.

 

I have examples where test code in a function results in coverage % X, but if the code is moved from the function directly into the test method, the coverage changes to Y%. And there are other cases where switching calls A() and B() to B() then A() changes the test coverage values (in these cases, A() and B() simply exercise properties of separate classes).

 

I read on other posts that the web-based test-coverage tools are more helpful that the IDE. The example in the post I just read was that the web-based tool will show code hit in the test path with blue and code not hit in red. What follows is one weird example:

WebService static Integer Save( String accountName, String address1, String city, String state, String zip, String
emailAddr, String bizPhone, String cellPhone, String sfAccountId, Boolean setToFalseForTesting ) {

gdirectws.gDirectWebServiceSoap gs = new gdirectws.gDirectWebServiceSoap(); 

if( setToFalseForTesting == true ) {

acctId = gs.Save( accountName, address1, city, state, zip, emailAddr, bizPhone, cellPhone, sfAccountId );

}

return acctId;

}

 

In the code above, the whole method shows as blue (i.e. covered in the test) EXCEPT for the return. I assumed that could only be the case if there was an exception in the gs.Save call, but no exceptions are reported during the test.

 

Is the test coverage calculator unusually buggy? Is this whack-a-mole nonsense just something that salesforce development entails? Or is it really just me?

jshimkoskijshimkoski

I just have a quick comment about your test function... acctId doesn't seem to be declared correctly... Shouldn't it be:

 

Integer acctId = gs.Save(.....

 

And, because acctId is declared inside the if block, doesn't that mean it won't necessarily be created in every instance, which would result in a problem on the return line?

 

I may have read it wrong but those are my first thoughts when I look it.

opiedogopiedog

Thanks for taking a look at this, jshimkoski.

 

FYI, I stripped out a few lines of System.debug calls to make the code more readable and accidentally removed the Integer acctId = -line.

 

Since posting this last night, I started over from scratch and I'm more convinced now than before that the calculations, presentation of code coverage, errors synchronizing with the server, and/or IDE messages are buggy. I was able to hack through most of the issues but it's frustrating to have to deal with such crap. This is not an overly impressive set of development tools here...

mshelmanmshelman

These issues  have been going on since the Apex Test Execution item was added to the Setup menu (Summer '11?) and there are numerous threads concerning the issue. The incorrect reporting of test coverage, wrongly placed red and blue lines in the coverage display, etc.  At one point we requested support to fix the problem and they fixed one of our sandboxes - and I got the idea that it is something that goes haywire on a particular org/instance rather than something that is fixed system-wide.

 

I work at a very large organization. We have been doing monthly deployments (just finished one this weekend) and our production instance coverage hovers around 68% - we have to assume that it is a bug since code cannot be deployed unless there is at least 75% coverage.

 

Mike