+ Start a Discussion
jacoclockedjacoclocked 

When did salesforce require code coverage of 75%

I'm curious to know how some of the code in my organization is working and was deployed as the code coverage is less than 75% for many of the triggers/controllers.  

 

I see that the creation date for most of the code is 2011.  Is this a recent requirement Salesforce implemented? (i've only been working with SFDC for about 4 months).  I know if I deploy code with less then 75% coverage, the code will not deploy. 

 

It would make sense to me that SFDC implemented this requirement and allowed code in production to continue to run even though the coverage was less than 75% but going forward would force developers to meet the requirement.  Any insight that can be provided would be of great benefit to me. Thanks!!!

 

 

Best Answer chosen by Admin (Salesforce Developers) 
sfdcfoxsfdcfox

If memory serves me correctly, the 75% requirement has been around since almost the time of release (I didn't do any professional work with the early versions of Apex Code, back when triggers needed a "bulk" keyword, so I don't remember when that feature came out).

 

There was always a requirement that code be tested automatically so as to prevent buggy code from being deployed (at least, in theory).

 

Regardless, code coverage can drop below 75% if the tests started failing for some arbitrary reason. Common causes include hard-coded ID values being used (and the related record being deleted), addition or changes to validation rules, and other system administration changes that can cause the tests to fail without any changes to the code.

 

Note that even though "many of the triggers/controllers" have "less than 75%" coverage, the value is weighted by number of lines.

 

For example, if you have 10000 lines of code in your organization, and one class is 9000 lines of code with 100% coverage, then the remaining 1000 lines of code require no coverage at all, and may be at 0% (except for the 1% trigger rule).

 

Note that this is definitely ill-advisable, but developers in a rush will cheat the system that way. For example, the 9000 line file might simply be:

 

public class Trick {
  public static void orTreat() {
  int x = 0;
  x++;
  x++;
  // another 8997 x++;
  }
  @istest
  static void test() {
    Trick.orTreat();
  }
}

This class would easily pass at 100%, and would inject 9000 lines of coverage" towards your total coverage.

 

Often-times, a healthy organization (one with all 100% coverage) loses a developer and gains another, and the new developer doesn't know about testing and/or ignores testing and/or doesn't know how to increase coverage on what they wrote, so they leave low-covered classes in place without seeking help, since the grand total is still over 75%. In this case, they will usually wait until there is a problem (e.g. code won't deploy because they are at 74%), and by then, they have to play catchup.

All Answers

Rajesh SriramuluRajesh Sriramulu

Hi,

 

If in prod there is average code coverage of all is 96% and you have one class with 70% in sandbox.

 

As u think this class cannot be deploy to prod?

 

No. it can be deployed to prod because salesforce will check the total average code coverage in prod and it calculate if >75% means it will deployed.

 

Please let me know if any concerns.

 

Regards,

Rajesh.

Manos SpanoudakisManos Spanoudakis

The requirement is from the early days I guess (I started working 03.2010 and was already in place)

 

There are quite a few reasons why Code coverage drops. Below you may find a couple 

 

1) New validation rules kill your test data and thus the methods terminate early before really testing

2) Batch job Test methods may start to fail when there are more than 1 batches in your Test Context (bad practise)

3) Deactivated users were used in your Test methods (bad practise)

4) Hardcoded Strings were used for e.g. Recordtype names and now Translated Recordtypes cannot be retrieved (very bad practise ;-) ) 

 

I know these are too generic, but I can only make assumptions ;-)

sfdcfoxsfdcfox

If memory serves me correctly, the 75% requirement has been around since almost the time of release (I didn't do any professional work with the early versions of Apex Code, back when triggers needed a "bulk" keyword, so I don't remember when that feature came out).

 

There was always a requirement that code be tested automatically so as to prevent buggy code from being deployed (at least, in theory).

 

Regardless, code coverage can drop below 75% if the tests started failing for some arbitrary reason. Common causes include hard-coded ID values being used (and the related record being deleted), addition or changes to validation rules, and other system administration changes that can cause the tests to fail without any changes to the code.

 

Note that even though "many of the triggers/controllers" have "less than 75%" coverage, the value is weighted by number of lines.

 

For example, if you have 10000 lines of code in your organization, and one class is 9000 lines of code with 100% coverage, then the remaining 1000 lines of code require no coverage at all, and may be at 0% (except for the 1% trigger rule).

 

Note that this is definitely ill-advisable, but developers in a rush will cheat the system that way. For example, the 9000 line file might simply be:

 

public class Trick {
  public static void orTreat() {
  int x = 0;
  x++;
  x++;
  // another 8997 x++;
  }
  @istest
  static void test() {
    Trick.orTreat();
  }
}

This class would easily pass at 100%, and would inject 9000 lines of coverage" towards your total coverage.

 

Often-times, a healthy organization (one with all 100% coverage) loses a developer and gains another, and the new developer doesn't know about testing and/or ignores testing and/or doesn't know how to increase coverage on what they wrote, so they leave low-covered classes in place without seeking help, since the grand total is still over 75%. In this case, they will usually wait until there is a problem (e.g. code won't deploy because they are at 74%), and by then, they have to play catchup.

This was selected as the best answer
Robert HowellRobert Howell
Hey @sfdcfox, in Developer Console I receive the "Problem" of "Defining type for IsTest methods must be declared as IsTest" at the line of code "static void Test() {". As far as I can see I have implemented exactly as demonstrated by you above. Any idea what I am doing wrong?
Steve Nahm 3Steve Nahm 3
Robert, tests need to go into a separate class, not in the same class as that being tested. Reference: 
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_unit_tests.htm

"Starting with Salesforce API 28.0, test methods can no longer reside in non-test classes and must be part of classes annotated with isTest."