function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
tonantetonante 

A Couple Questions Regarding Apex Test Execute and Code Coverage

 I have just run Apex Test Execution in my production org and I am seeing a coverage of 75%!
1) We have recnetly loaded a bunch of Managed packe files like Non-Profit Starter pack etc.)  and some of those test cases failed during Apex Execution.
2) I found that we have old files that are at 0% in the org left by earlier consultants that I believe we don;t need anymore.

IN order to increase covrage should I:

1) Remove old unused classes with 0% coverage ? (Placed somehow by other consultants) Doesn;t that at least give and extra increase of 1% code coverage?

2) Compile the Managed packages before running the Apex Test Execution? (I never  compiled them  before running Apex Test Execution)

Thanks much for your help.
 
Best Answer chosen by tonante
James LoghryJames Loghry
The Managed Package code has no bearing the actual code coverage in your org.  They are run separately from your own unit tests.  

In order to improve your own code coverage beyond 75%, yes, I would take a look at files you could remove.  You'll likely need to do this with destructiveChanges.xml (google it for more information).  Since code coverage is calculated by lines covered / total lines, you're percentage will not necessarily increase by 1% of course, it may be less it may be more.  

I'd also take a look at your other classes and determine ways you could improve code coverage across them.  (For instance, you can sort the classes by file size, and look at the % of code covered.)

Good luck,

All Answers

James LoghryJames Loghry
The Managed Package code has no bearing the actual code coverage in your org.  They are run separately from your own unit tests.  

In order to improve your own code coverage beyond 75%, yes, I would take a look at files you could remove.  You'll likely need to do this with destructiveChanges.xml (google it for more information).  Since code coverage is calculated by lines covered / total lines, you're percentage will not necessarily increase by 1% of course, it may be less it may be more.  

I'd also take a look at your other classes and determine ways you could improve code coverage across them.  (For instance, you can sort the classes by file size, and look at the % of code covered.)

Good luck,
This was selected as the best answer
tonantetonante
Thanks EDL James. It also seems like my managed package classes are the cause of some of the failures in local test classes. for example npe01 is the alias for a managed package for Non-profit Starter Pack and NewCampaignMembersBeforeInsertManager is my local trigger: NewCampaignMembersBeforeInsertManager System.DmlException: Insert failed. First exception on row 0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, npe01.IndividualAccounts: execution of BeforeInsert caused by: System.DmlException: Insert failed. First exception on row 0; first error: UNABLE_TO_LOCK_ROW, unable to obtain exclusive access to this record: [] (*npe01*) : [] .
James LoghryJames Loghry
Yeah, the unable to lock row errors you see in the dev console are typically intermittent / timing issues, and I tend to ignore those.  If you re-run the test individually, it should pass if your test is correct
James LoghryJames Loghry
And by dev console I meant either the dev console or test execution pane.
tonantetonante
I will look into scrubing the test cases because now I have one last error and that deals with Mixed DML operations where a non-setup and setup object are doing DMLs actions within the same transaction (usually a test method). Thanks James for your help and I do see 2 test cases out of 51 that have failed.