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?

closed as primarily opinion-based by metadaddy Feb 4 '14 at 1:05

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


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
    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 '14 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 '14 at 23:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.