Develop Console Code Coverage Issues (Winter 15′ Release) – Production vs. All Test

Wondering if this is a bug or there is something about CC that just doesn’t make sense to me.

Below is screenshot after screenshot of example of red-lined code coverage that makes no sense. Everything from commented lines, System.debug lines, closing brackets, dynamic SOQL statements, etc.

Extra line of SOQL statement

Commented header

Closing bracket

System debug

Also you can see here there is definitely an issue with the overall code coverage numbers. Mind you everything I’m showing you are the results both directly from our production AND from a fresh sandbox with only one test class being run in order to isolate the issues as much as possible.

Overall CC on cached file?

Any thoughts on this would be great, even if its just confirming there is a known bug and I’m not crazy. This is all just from 1 file but there are plenty of other example I have just like this.

Also, I have already reset/cleared all test data multiple times and re-run all test to make sure this result is as accurate as possible.

Thanks in advance for any help!

Answer

UPDATE: SOLUTION (4/16/15)

Thanks to a buddy at SF I found this documentation that shows you how to clear the cache I was referring to so that the perceived code coverage (that which appears from “running all test”) will now match actual code coverage (that which is calculated at deployment along with your changes of course).

Follow the steps provided here:
Code coverage steps and considerations prior to deployments

Essentially the problem is the code coverage is accumulative, meaning that even if you “Clear Test Data” the lines that were covered are still stored in these other aggregate tables. Once you follow the steps and clear everything manually, as well as recompile your classes then you truly have a clean slate to THEN “Run All Test”

Clear this table (make sure to check “Use Tooling API”):

SELECT Id FROM ApexCodeCoverageAggregate

UPDATE: WORKAROUND (4/8/15)

So currently the only solution I’ve had to accurately test the coverage of a file at any given time is:

  1. Destruct/delete from the sandbox server

This apparently removes it from the console’s cache of some sort.

  1. Redeploy
  2. Clear All Test Data
  3. Re-run test

If you do not destruct/delete and redeploy then the new lines covered seem to get added to the cached version and little by little your results are distorted. As you saw in the OP screenshots this can even lead to overall code coverage issues, claiming 15/15 are covered even though the file consist of hundreds of lines.


ORIGINAL ANSWER:

As per @Victor’s answer I posted a ticket. Took a few days to get a response and initially they wouldn’t even help because we apparently do not have developer support (typical SalesForce support to not even read your problem before quoting you your licensing limits).

Anyways, after a call to a sales rep they they finally looked into the issue and responded with the following:

Connection User 04/01/2015 10:09:34 AM PDT

Hi Nick,

I further checked on this and found that yes we are experiencing
issues with test class at our end
.

The bad line coverage issues as you mentioned on stack trace has not
been identified as bug though
but I checked that many customers are
complaining the same.

Since this is been complained by plenty of customers our R & D team
will take notice on it and might create a public known issue link for
customers.

There are other issues too , related to test class only, for instance
https://success.salesforce.com/issues_view?id=a1p30000000T4oRAAS

Bottom line is – as of now no known issue is published for your
concerned problem however I confirm that other users are also facing
the same so we might see a bug link on it.

Recompilation and clearing Test execution history might help but
sometimes it doesn’t
.

Kindly let me know if you have any other concern too regarding this.

Thanks, Ashish Developer support salesforce.com

The patch for the related issue is set for an October release but if the problem proves to be bigger than they expect then it can be sooner so be sure to add any details you know about this so we can inform them.

Attribution
Source : Link , Question Author : Xtremefaith , Answer Author : Xtremefaith

Leave a Comment