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
nfon teamusernfon teamuser 

Drop in code coverage on production

Hello,
we are experiencing an code coverage problem on our production environment. Last week we deployed an change set without any issues and the code coverage was at 75%. 3 days later we tried to deploy an other change set, but this has failed do to code coverage error. The code coverage is now at 73%. The problem is, this change contains no code and is only an flow.
There were no changes to any code in those 3 days and no changes to validation rules or work-flows (checked via audit trail), all tests succeed, the only problem is in the coverage. We are generating our test data via factories and using seeAllData=false and aren't using any record in the org for testing.
The code coverage was at 75% at the time of the deployment of the first change set, it would not deploy otherwise. How is is possible, that it is only 73 now?
Classes recompiled, test history deleted, we get the 73% when deploying or running all tests(UI and IDE).

I have found this issue on the forums
https://success.salesforce.com/issues_view?id=a1p30000000T1m1AAC
and have checked the ApexCodeCoverageAggregate, but there is no problem.

I have even tried to validate an change set containing 600 lines of i++; (I know, ugly) and haven't got even 1% more coverage. We are currently using about 2M chars of code.

This is an blocker for us, any help would be appreciated.

Thanks.
Best Answer chosen by nfon teamuser
Simon ReparSimon Repar
I figured it out that SF has probably changed the functionality which is responsible for code coverage. See attached example. Current situation is that a1,a2 variables are not covered, because they are not set in any method (or constructor). I am almost sure that 14 days ago a1,a2 variables would get covered...

I suppose this is root cause why everyone gets few percent lower code coverage as prior that change. You have to be careful that you use all of the variables in classes or set them in test. 

The key question is why Salesforce has suddenly changed this behaviour. We have problems with the code coverage in 80 % of our orgs from that change on...
User-added image

All Answers

Sakonent Admin 10Sakonent Admin 10
You have to rerun all test classes and see which apex class or trigger coverage goes down. It's common behaviour of Salesforce that when you create new validation rule or flow, it'll impanct few of test classes code covergae and it goes down and effect overall code coverage. Therefore, its better to analyse which apex class or trigger coverage goes down after rerun the test classes.
nfon teamusernfon teamuser
Hello,
but we haven't created any validation rules or flows, there where now changes to the org setup in those 3 days.

We have about 220 classes and 50 triggers, it is not easy to see where the coverage has dropped, plus I have no way to compare it to the "old" coverage.
Sakonent Admin 10Sakonent Admin 10
But you have mentioned in your post "The problem is, this change contains no code and is only an flow"
nfon teamusernfon teamuser
Yes and this change set could not be deployed, after that i have tried to run all test and got 73%, then I tried to deploy the i++; class and got 73% as well.
Puru AnnamalaiPuru Annamalai
Hi,

try the below approach, and check the coverage
Go to -> Apex Test Execution -> Settings ->  CHECK Disable Parallel Apex Testing

then compile and run the coverage.
nfon teamusernfon teamuser
Hi,
sorry I forgot to mention that, I have already done that, 73% with sequential testing, 74% in parallel testing. But this is only an estimate, so I think here is not the problem.
nfon teamusernfon teamuser

Hi,
so I got the solution, sort of.
We had a class containing about 1000 lines of code. Later on, this class became obsolete, so we commented the whole inside of the class out and left the code as it is if we need it in the future. Comments do not count to you code limit at should not count to the code coverage, the problem is, they do.
When you have a class where not a single line is covered, every line in the class, even comments are counted towards the code coverage.
By only deleting this class, containing only 1000 lines of commented code I got 2% code coverage.

We have more classes like this and we are now cleaning the whole production from them.

No Idea why it started to cont these lines towards the code coverage.
Simon ReparSimon Repar
I figured it out that SF has probably changed the functionality which is responsible for code coverage. See attached example. Current situation is that a1,a2 variables are not covered, because they are not set in any method (or constructor). I am almost sure that 14 days ago a1,a2 variables would get covered...

I suppose this is root cause why everyone gets few percent lower code coverage as prior that change. You have to be careful that you use all of the variables in classes or set them in test. 

The key question is why Salesforce has suddenly changed this behaviour. We have problems with the code coverage in 80 % of our orgs from that change on...
User-added image
This was selected as the best answer
nfon teamusernfon teamuser
Hi,
I knew It! That would explain our drop of 2%. It seems, you have to keep your ors at 80% to compensate for these problems.