45
votes

I'm running EclEmma, the Emma plugin for Eclipse, and the coverage report shows only partial coverage for an Enum I've defined, even though it shows the only value in the Enum as being covered. I'm assuming that there is a coverage gap for the implied methods that back the Enum, but I'm not quite sure.

For example, with this Enum, EclEmma highlights everything in green, except for the package declaration:

package com.blah;

public enum UserRole {
 HAS_ACCESS
}

If I pull up the coverage details for the class, I see this:

alt text

My question is, what is the best way to get 100% coverage on my Enum classes using EclEmma?

3
My 2 cents as I have been there before and I've seen my developers falling into this trap. Feels like you are more passionate (than desired) on reaching the 100% code coverage . This is just waste of time. Coverage tool reports should just be used to identify code improvement opportunities (or reducing technical dept) and should not be seen as MUST fixes. - Aravind Yarram
Does Emma not give you details about what you missed? That seems kind of odd. - Mark Peters
I agree, but if there is a simple way to get the coverage, I'm not going to ignore it. It is noise on a coverage report that I'd rather not have to filter through to get to real issues. I see it like not having any compiler warnings. I don't have to fix them all, but I don't want to filter through the less important ones to see that I have a new one that is pretty important. BTW, your answer is a non-answer and would have been better placed as a comment. - Javid Jamae
Agree...i wish i could move it to a comment now...i didn't think much if this is a comment ;-) - Aravind Yarram
I agree but you can only market your code/framework/whatever with the "it has 100% test coverage" sentence if it really has it. Sad but true. +1 - Adam Arold

3 Answers

57
votes

What you're seeing is some hidden bytecode being generated due to an enumeration.

To get rid of this issue, add a call to the values() and valueOf() methods in the enum, as mentioned earlier by Carl Manaster and Peter Lawrey.

10
votes

I agree with other posters that 100% code coverage can be misguided. But I have to admit to the satisfaction of getting 100% coverage on newly written core code.

Fortunately since all enums extend the same 'class', you can achieve your 100% with a little help from your friend reflection.

Just add the following static method in a class for your testers to call, using [EnumTypeName].class as a parameter.

  public static void superficialEnumCodeCoverage(Class<? extends Enum<?>> enumClass) {
    try {
      for (Object o : (Object[])enumClass.getMethod("values").invoke(null)) {
        enumClass.getMethod("valueOf", String.class).invoke(null, o.toString());
      }
    }
    catch (Throwable e) {
      throw new RuntimeException(e);
    }
  }

Assuming this static function was implemented in a class called "Shared", you would only need to include this line for each enum:

Shared.superficialEnumCodeCoverage(UserRole.class);

The key word is 'superficial'.

2
votes

We ran into a similar issue where the compiler generated methods on enumerations, like values(), typically were not being called in our test code. We worked around the problem by filtering the numbers of our enum objects out of our final report.

This is why I don't like using code coverage as a measure of completeness. When I think of a better metric, I'll let you know. :)