What's the story?
On a recent project I started looking at a Salesforce ORG with low code coverage. The overall coverage was actually lower than 50%.
This is a potentially huge headache as Salesforce blocks new code deployments if your code coverage is below 75% in your production environment.
So how do you improve it?
There are several ways to go about fixing up an ORG's code coverage. The 75% is driven by the percentage coverage of all Classes and Triggers so looking at those in detail is a good starting point.
Spring cleaning
Looking at each of your classes in detail in the Developer Console may give you an immediate list of individual classes/triggers that have low coverage. I would recommend sorting your classes by the Percent column so you can immediately find the likely suspects.
Once you know which classes need sprucing up or removing. Just removing a few really classes can bring down the overall % significantly. However, you cannot remove them directly from your production environment (easily) so keep reading on what to do next.
Remove the unused
You may spot classes/triggers that are part of an unmanaged app/package.
- Are you still using that app?
- Is a newer version available?
- Can the provider give you improved version with better code in it?
If it's not in use and/or supported, then removing the package and its low coverage code may well bump up your total %.
Take a backup first and sense check removing the app with your coworkers - someone out there may be regularly using it.
Next step - deleting/commenting out code
After completing the steps above my customer's code level had increased slightly but there were several classes in their production environment with 0% to deal with.
As a next step, I could either look at:
- writing a test class from scratch to cover the class
- trying to delete the class directly from the production environment
- trying to deploy an updated version with the class commented out
Lets take a look at each one of these in more detail.
Writing a test class for inherited code is likely to be very time-consuming. I would recommend being very sure that the class is needed before embarking down this path.
Trying to delete a class from Salesforce production (once you've confirmed that the class isn't being used) can be achieved using a range of tools - more information on how below) but I would flag this as a high risk approach. You're making an irreversible change direct in your live environment. Be very sure that deleting the class won't impact anything before doing this.
Success Community links
Delete Apex Trigger/Apex Class from Production
Finally, we have the option of deploying updated code via a change set. This at least gives you the audit history on the change, and utilizes Salesforce inbuilt verification steps.
So, how do you improve the code coverage of the class without having to retro-fit a detailed test class around it?
For several of the remaining classes in my customer's ORG, I commented out the code, leaving only the class header and footer, and then created a test class using a very repeatable pattern to ensure that the reduced class had 100% coverage.
Here's the pattern for a commented out class.
The Class
//The variable after public class will be referenced in your test class
public class CommentedClass {
/* Lines of commented code - put your old code here */
}
The Test Class
To ensure that the reduced class has code coverage we create a new instance of it and assert that it was created succesfully.@isTest
//format is test & name of class/trigger you are testing
private class testCommentedClass{
// the variable name after void can be anything you like
static testMethod void testCommented(){
Test.StartTest();
//The object name below has to match up with your trigger/class
CommentedClass obj = new CommentedClass();
//This one link is asserting that you successfully created it
system.assertNotEquals(null,obj);
Test.StopTest();
/* Rest of legacy code if you have it */
}
}
Once you your updated Code and Test Class you can package them into a change set and get ready to deploy.
Hang on...
Now, you may be thinking "you said that you cannot deploy new code if the Org is below 75%!"Well, whilst that is indeed true I found one useful workaround (thanks once again to the success community. can deploy specified pieces of code to production as long as the test coverage within the Change Set is above 75%.
When deploying the change set make sure you select the 'Run Specified Tests' option and copy in the name of the test classes within the change set. When selecting that option, Salesforce will only look at the coverage of the classes in the change set and this bypasses the 75% block (as long as the test coverage of the new classes is good).
When the updated code is deployed, not only have you reduced the overall lines of code (increasing the % covered) but you've also given 100% coverage to the remaining reduced lines.
If you don't immediately see the code coverage improve in your production environment, in the Apex Classes page click on:
- Compile All Classes and
- Run All Tests
and wait for the tests to complete.
Research
Once again the Salesforce Success Community was a huge help in creating this test pattern. I looked through so many posts on dealing with this issue.
However, the post below gave me the best start on this mini-test class. I just needed to add the .assert statement to clear 100%. Thanks Maruf Bagwan!
Image from Pexels. com, artist Kevin Ku
Comments
Post a Comment