[SalesForce] Test Coverage for ENUM, Properties – Differences with default value, no values, and getters/setters

Maybe I am remembering wrong but I think things have changed and I missed the document. Back to basics with this question

For a class that has no methods and is just ENUMS:

public class muENUMS{ //does not even show up in test coverage not even as 0/0 lines

    public enum anExample{
        TryMe,
        YetAgain
    }

}

Salesforce says there are 0 lines to cover (in fact it never even appears in list of classes that can be covered) and during tests nothing is ever covered despite the enums being used.

Another example without enums:

public class coverageExample{ //Shows as 1 of 2 lines covered just by instantiation

    public String thisLineNotCountedOrCovered;
    public String thisLineCountedAndCovered = 'A String';
    public String thisLineCountedAndNOTCovered {get; set;}

}

So my questions in the context of just instantiating the class):

  1. Has this always been the case?

In the enum class no coverage data is calculated and the lines do not count toward to total lines to cover

In the other class it counts as 1 of 2 lines covered. The first property is not counted nor covered. The one with the getter / setter is counted and not covered.

  1. If it has not always been the case, can someone point me to the document that outlines the change? Google failed me.

It seems if a property is defaulted to a value it counts as a line of code to cover and gets covered. If a line is just a property declaration without a getter / setter it is not even considered for coverage. If it is declared with a getter / setter it is counted and if not accessed it is not covered

I believe it is important to understand this as it really impacts the access the developer gives code. Many are used to just adding getters / setters even if they are not needed. In the above that decision creates unnecessary coverage requirements.

Best Answer

Enums, interfaces, abstract methods, class-level declaration statements, class definitions, and debug statements never count for code coverage. Everything else does, including getters and setters, non-abstract methods (including the method signature), class-level assignments, and every non-debug line of code within a method always count for coverage.

Has this always been the case?

Yes, it's been this way since the inception of Apex, as far as I can remember.

In the enum class no coverage data is calculated and the lines do not count toward to total lines to cover

Yes, it is a "class-level declaration statement," and thus has no coverage.

The first property is not counted nor covered.

It is a class-level declaration statement, and thus has no coverage, either.

The one with the getter / setter is counted and not covered.

This transforms the line from a class-level declaration statement to a method signature statement, thus requiring coverage.

It seems if a property is defaulted to a value it counts as a line of code to cover and gets covered.

Yes, any time you use the = operator, it is no longer just a declaration, it is an executable statement; you're assigning a value to a variable.

Yes, there are plenty of ways to make more work for oneself, and one of them is to unnecessarily declare default getters and setters. They are strictly only necessary for Visualforce attributes, and should not be used otherwise without a reason.

I think more to the point, it is up to each developer to learn all of the particular tools in which they use (in this case, the various parts of the Apex language) to write the most optimal code possible. Unfortunately, we have a lot of poorly written resources out there that newer developers prefer to read than to check the official documentation, which further perpetuates the cycle.

This problem is further exacerbated by the fact that the documentation team, despite doing a pretty good job at what they do, presume that the readers have a decent history in Java, C#, or another related language. The "obvious parts", like why { get; set; } causes code coverage, isn't in the documentation. It's presumed that the reader knows that these are really methods, and all methods require code coverage.

Related Topic