The most sneaky way to increase your code coverage [closed]

I would like to share here this just for fun and as an example of what you should not do to pass the 75% of code coverage needed on SFDC.

Maybe is not to much constructive but I think is funny to see how other developers solve problems.


I had today the good look to work on a existing project which was made for other company. I found a “funny” and really dirty way that was used on a class just to achieve the minimal amount of code coverage.

The org has 10 classes and I found that all of them had an static method called fakeMethod. Then I found one test class that contains only one method calling those fakeMethod for each class.

The content of the fakeMethod was:

Integer i = 0;
.... //repeat that i++ hundred of times. (some time other no-sense instructions)

Complete sample:

class A{

  public void realMethod(){
    //real code
  // other methods

  public static void fakeMethod(){
    Integer i = 0;
    //repeat the i++ hundred of times


class globalTest{

  static testMethod void fakeTest(){
     //repeat the same for the rest of classes.


It is unbelievable for me how the developer breaks the complete meaning of unit-test and code coverage on SFDC for me.


Does anyone a worst sample of what not to do just to pass the code coverage?


We were taught that trick by a platinum level (df) consulting company. It will bite you in the butt if you try to get an increase in code size limit. They review your test code carefully after so many increases.

Re: the question at the end – Worst thing I’ve seen next to that percentage hack (that is by far the worst) is using SeeAllData=true just to make sure they have the production data, instead of just writing out the code to create proper test data. Third to that is adding flags to the class to trigger sections of code to run during a test (okay in some cases, but not all).

Source : Link , Question Author : Martin Borthiry , Answer Author : drakored

Leave a Comment