11

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!

  • I think this has been a random problem for awhile. Clearing all test results was always the fix, but it sounds like you tried that already. Is your screenshot from an IDE or the Developer console? – CyberJus Mar 25 '15 at 20:02
  • That's the developer console. And yes, code coverage is usually odd/off in many non-trivial classes without a "run all tests". – sfdcfox Mar 25 '15 at 20:06
  • This is directly from the developer console – Xtremefaith Mar 25 '15 at 20:06
  • I literally just cleared all test data and re-ran all test again, unfortunately the problem still exist but so new info. 1 of my Utility classes had 1 small method in it with 75% (3/4) CC, now I've added 40+ lines of new code in a new method but the developer console still shows OpportunityUtils.cls - 75% (3/4) It seems across the board there are old files in cache, but from console I can open them and see the correct version. – Xtremefaith Mar 25 '15 at 20:33
  • @Xtremefaith I have an independent tool that will highlight the code coverage based on the ApexCodeCoverage.Coverage that is exposed via the Tooling API. It won't correct problems with the line numbers there, but may help if the issue is with the developer console line identification. You could also double check that the ApexCodeCoverage is empty before starting the tests. – Daniel Ballinger Mar 26 '15 at 1:24
7

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.

|improve this answer|||||
  • We heard that it was definitely a problem with na15. I don't know if that matches OP or your experience. – Jeremy Nottingham Apr 3 '15 at 1:26
1

It appears that with Spring 15 updates to Apex Classes via the Metadata API are corrupting the Aggregate Code Coverage results. See Known Issue: Updating an Apex class through [Metadata API] makes its code coverage corrupt.

As you have found, manually deleting the ApexCodeCoverageAggregate records via the Tooling API can be used to work around the issue.

|improve this answer|||||
0

It happened to me in past. Finally we ended up raising ticket with salesforce.com. Just attach the same screenshot in your ticket, it is somewhat common issue. They will resolve soon.

|improve this answer|||||
0

One way to resolve will be to clear all the test execution and clear your Test execution history .This is common issue .

|improve this answer|||||
0

You can use Atom to run them all. Once all the class coverage are above 75%, you can deploy them all.

|improve this answer|||||
  • 1
    Does this clear the issue with the bad coverage metrics? – Matt Lacey Mar 26 '15 at 5:56
0

Go to workbench and perform the following steps:

1) Via rest explorer, run the following on the ApexCodeCoverage table: /services/data/v29.0/tooling/query/?q=SELECT+Coverage,+TestMethodName,+ApexClassOrTriggerId,+ApexClassOrTrigger.Name,+NumLinesCovered,+NumLinesUncovered,+ApexTestClassId+FROM+ApexCodeCoverage+WHERE+ApexClassorTriggerId+=+'01pD00000014Z3c'

2) Open the record then attributes folder and Click on the URL like:

records [Item 1] attributes type: ApexCodeCoverage url: /services/data/v29.0/tooling/sobjects/ApexCodeCoverage/714L000000A3JGeIAN

3) Once the record opens, choose the delete action and press execute to delete the entry

3) Now run the query on the ApexCodeCoverageAggregate table: /services/data/v29.0/tooling/query/?q=SELECT+ApexClassOrTriggerId,+ApexClassOrTrigger.Name,+NumLinesCovered,+NumLinesUncovered+FROM+ApexCodeCoverageAggregate+WHERE+ApexClassOrTriggerId+=+'Class ID'

4) Again go to the URL under the attributes folder and Click on the URL like. Once the record opens, choose the delete action and press execute to delete the entry

5) Open the "affected class" and you should now see: "Código cubierto 0% (No coverage data)"

6) Run the myUnitTests test class and this should have the correct count.

Please let me know in case of any concerns.

Regards, Vartul Mangla

|improve this answer|||||
0

I had this the other day. A fix that worked for me was: (in developer console) create a dummy edit on the file in question. It seemed as though there was some cached information that hadn't been updated.

|improve this answer|||||
  • Can you do this in production though? – Xtremefaith Mar 30 '15 at 18:44
  • @Xtremefaith yes, assuming appropriate permissions. – powlo Mar 31 '15 at 18:47
  • 1
    Even with admin permissions you cannot edit an active production environment, it has to go through deployment and unit testing – Xtremefaith Apr 2 '15 at 20:28
  • Ah that seems to be correct. My solution only works for developer orgs. See here: help.salesforce.com/apex/… – powlo Apr 7 '15 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.