14

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.

Case

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;
i++;
i++;
.... //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;
    i++;
    //repeat the i++ hundred of times

  }
}

@isTest
class globalTest{

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

Opinion

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

Question

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

4

1 Answer 1

5

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).

3
  • 3
    I've done the i++ thing myself; 1st time was a frustration response to the platform's poor tools and glitches that had me backed into a corner. I really take issue with their 75% enforcement; it's far better to have thorough coverage over the few pieces difficult/critical logic than 75% over everything -- including getters and all the other syntactic fluff you end up writing in Apex. This is one more design aspect of the platform that takes the decision-making/control out of the developer's hands; when you add up enough of these, you get a platform that's very tough for large dev efforts.
    – mulveling
    Feb 3, 2014 at 23:08
  • Couldn't agree more. I find people are more likely to work around it than to actually adopt test driven practices. It becomes a burdening after thought because it is tedious. They tend to do it at the last possible minute.
    – drakored
    Feb 3, 2014 at 23:15
  • 1
    This comes in handy when there is absolutely zero way provided by salesforce to test alot of the methods in the Site class ie. changePassword(s,s,s) and validatePassword(User,s,s) and I hate this solution as well but what are we going to do when we need to test calls that hit that class and they provide no way to do do so and we want a legit amount of coverage?
    – ChiCloud
    Oct 14, 2019 at 0:54

Not the answer you're looking for? Browse other questions tagged .