1

In my new project the existing team complained that they faced deployment issues due to poor code coverage.

When I ran "Estimate Organization Code Coverage" in the production instance under Develop->Apex Classes I saw the below

enter image description here

a) How come it is possible that the code coverage in the production can be less than 75 % ?..Because as far as I know any apex class push into Production will trigger all test classes and the entire org code coverage will be calculated. When this being the case I am not able to understand how come the code coverage of a production instance can be this low as 55 % ?..Can someone throw some ideas ?

b) Will there be any detrimental effects if I execute "Run All Tests" in production instance ?..Like how any Apex class cannot be deployed if there is a scheduled job (of the same apex class)..is there something like that for test classes also ?...Will running "Run All Tests" in production cause any performance issues ?

1
  • Config changes in live can break tests, e.g. a new validation rule causes a test to fail - then your code coverage will fall.
    – Girbot
    Sep 17 '15 at 13:00
2

You are right code is pushed only if the overall code coverage is greater than 75%. However, as the developers and release managers develop more custom code and in emergency releases they forget to update the related test classes. And as the code in classes increases the code coverage decreases. Then comes a time when after a deployment the code coverage goes below 75% and post that it is impossible to deploy any further code. Unless you fix the test classes or add new ones.

  1. As a thumb rule make sure with every release associated test classes are updated and are covering at-least 85% of code.
  2. Running all tests might take 15 minutes to a full day depending upon the total line of code in your org. Ideally it should not cause any performance issues. And before you hit the 'Run all tests' button please make sure you have cleared existing 'bad'coverage data. Refer to this link : https://help.salesforce.com/HTViewSolution?id=000206633&language=en_US

Thank you

3
  • Thanks...I ran the "Run All Tests" in production instance and I observed that most of the test class errors are because of managed package test classes..I would like to know whether there is any option available using which I can avoid running these managed package test classes and there by improving the code coverage ???..Is there any such option available ?
    – VPY
    Sep 17 '15 at 11:54
  • @AaronWilfred The easiest way to avoid execution of managed packaged test classes is to validate a package or a change set on production. While deploying or validation non-managed package classes are NOT executed. Refer to this link : help.salesforce.com/apex/…
    – Sf_Noob
    Sep 17 '15 at 12:00
  • I meant While deploying or validation managed package Test classes are NOT executed.
    – Sf_Noob
    Sep 17 '15 at 12:18
2

One of the ways that code coverage drops which many people aren't aware of is that when you enable certain features of Salesforce, you get new controllers automatically installed into your org that don't always have 75% code coverage or that contain methods that will fail without intervention on your part. These controllers need to have additional test code added to them that are customized to meet the requirements for your specific org.

One example that comes to mind is when you enable Communities. Expect 1 of the 11 test methods to fail. Ignoring that 1 method has failed, here's the coverage that gets listed for the controllers:

  • ChangePasswordController (100% class code coverage 6/6)
  • CommunitiesLandingController (33% class code coverage 1/3)
  • CommunitiesLoginController (100% class coverage 5/5)
  • CommunitiesSelfRegConfirmController (100% class code coverage 1/1)
  • CommunitiesSelfRegController (84% class code coverage 28/33)
  • MyProfilePageController (87% class code coverage 36/41)
  • SiteLoginController (100% class code coverage 6/6)
  • SiteRegisterController (82% class code coverage 23/28)
  • ForgotPasswordController (88% class code coverage 8/9)
  • Average code coverage for above code = 86% (114/132)

If you enable Chatter Answers, including enabling it for your Community, expect 2 of the 3 methods to fail. Ignoring that two methods have failed, here's the default coverage you get:

  • ChatterAnswersAuthProviderRegistration (51% code coverage 18/35)
  • ChatterAnswersRegistration (100% code coverage 4/4)
  • chatter_answers_question_escalation_to_case_trigger (42% code coverage 6/14)
  • Average code coverage for above code = 53% (28/53)

Further, in SU15, Salesforce instituted New Code Coverage Calculation for Multiline Statements. Prior to SU15, if you had code written as multi-line statements, each line counted as a single line which potentially had the effect of increasing your coverage. That's no longer the case. It now depends on whether or not the line is actually executed or evaluated during the test class. Here's an example where code coverage could go down:

//Lets say that opp.Id == null
//Previously, this would have been evaluated as four lines of code
//Under new rules, this will now be evaluated as only 1 line of code because 
//1st line fails & no need to execute additional lines in test
if(opp.Id != null
    && another var not eval
    && another var not eval
    && another var not eval)
   { //always ignored and not counted in coverage
      doSomething(); //Doesn't get executed under old or new rules when if condition isn't met

Under the above scenarios, you coverage could easily go down depending on whether or not you've covered all the compound lines in your if statement along with the order in which they're listed. So, this is something you'll want to be aware of that could be affecting your code coverage. There are other things that are covered in the link I've provided above.

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.