function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Mishael LegaspiMishael Legaspi 

Helper Methods for Test Classes

Upon checking the code coverage of our APEX Classes, we've noticed that a few of our actual Test Classes are evaluated as well. We found out that this is because of the non-test methods with parameters in our Test Classes. These methods are really just helper functions for the Test Classes, but it's frustating that they are the ones that cause the Test Classes to be evaluated in the overall code coverage numbers. (as described in https://help.salesforce.com/apex/HTViewSolution?urlname=Why-is-a-Test-class-evaluated-as-part-of-the-Organization-s-Code-Coverage&language=en_US (https://help.salesforce.com/apex/HTViewSolution?urlname=Why-is-a-Test-class-evaluated-as-part-of-the-Organization-s-Code-Coverage&language=en_US))

Is there any work around here? We also found out that the same pattern is actually used in the examples from the Force.com Apex Code Developer's Guide and the APEX Workbook. See https://developer.salesforce.com/docs/atlas.en-us.apex_workbook.meta/apex_workbook/apex_testing_1.htm and https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm. Does this mean that we also have to create test classes for those test helper methods?

Thanks in advance,
Mishael

 
Best Answer chosen by Mishael Legaspi
kibitzerkibitzer
Yes - I don't know what the people who wrote that particular solution were talking about when they said that only test methods should be in a test class. The pattern of using a non test method for data setup or common utilities is well known and is even present in the language reference as you noted. It's a good way to go, and I think they are making excuses for what is really a flaw in the code coverage calculations. They should be treating this as a bug, not telling you to avoid using this design pattern.

That said, it's not clear to me why you're having a problem. The whole purpose of having that common utility method in a test class is to use it in tests, so you should have no trouble getting very high code coverage values for it. In fact, if the class is being considered, it should - if anything, be helping your overall code coverage estimates, no?

 

All Answers

kibitzerkibitzer
Yes - I don't know what the people who wrote that particular solution were talking about when they said that only test methods should be in a test class. The pattern of using a non test method for data setup or common utilities is well known and is even present in the language reference as you noted. It's a good way to go, and I think they are making excuses for what is really a flaw in the code coverage calculations. They should be treating this as a bug, not telling you to avoid using this design pattern.

That said, it's not clear to me why you're having a problem. The whole purpose of having that common utility method in a test class is to use it in tests, so you should have no trouble getting very high code coverage values for it. In fact, if the class is being considered, it should - if anything, be helping your overall code coverage estimates, no?

 
This was selected as the best answer
Mishael LegaspiMishael Legaspi
Thanks for the feedback, kibitzer! Actually, it doesn't help because we get a "0" code coverage on that test class for some reason. We also think that there might be a bug in the IDE we use (ASIDE.io) where we got the report of all the text coverage results. But anyway, it's good to know that we're not doing anything wrong. :)
Edward BrownEdward Brown

I know this is an old thread, but in case Mishael or anybody else is looking for a halfway decent solution to this, I found something that worked for me. There is an annotation that allows you to expose a class's variables to test classes that refer to it, @TestVisible. I was able to make a helper function for my test class by using the following pattern:

/* In the class you want to test... */
public class Foo {
    // include your helper function(s) in the class that you will be testing
    @TestVisible private static void helperFunction (/* parameters as needed */) {
        // helper code here
    }
    
    // ... 
}

/* In your test class */
@IsTest public class FooTest {

    @IsTest static void testFoo () {
        // you can call your helperFunction from here
        Foo.helperFunction (/* arguments */);
    }
}
 

This still contributes to your code coverage metrics, but testing it is as easy as throwing an additional test case into your suite for the class that you are already testing.