IntelliJ IDEA: ignore trivial methods in code coverage

Question

In IntelliJ IDEA 15.0.2 how can I ignore trivial getters and setters (trivial methods) during test coverage measurement?

// should be measure
public void complex() {
    fancy();
    interesting();
    dropDatabase();
}

// should not be measured
public int getNumber() {
    return this.number;
}

Measuring every line would result in 75%. Measuring only the above method would result in 100%. And those are 100% of the code useful for testing.

How come I don't find anything about that on the Internet? Am I diving into bad practice?

UPDATE

This code is also eligible for testing:

// should also be tested as it contains logic
public Integer getValidationProgress() {
    if (validationProgress == null) {
        validationProgress = 0;
    }
    return validationProgress;
}

Answer 1

JetBrains told me that this is currently not possible .

Andrey Dernov (IntelliJ) Jan 6, 22:54

Hello Michael,

There is no setting to ignore a certain method.

I created an issue for that.

Answer 2

There is still no way to do that and this is a good thing. I understand your pain and I feel it too.

Lets assume you have an application that would have 100% code coverage if it were not for these trivial setters and getters. This means that all of your code gets exercised through your test suite except for the trivial setters and getters.

This raises the question why the trivial methods are there in the first place. If all of your code is run and the methods are not called then your 100% coverage is superficial. All the code is run, but not all use cases are tested. This is the precise reason why code coverage is deceiving.

There are the following cases:

1. The methods are never called anywhere and should therefore be removed.
2. The methods are called somewhere, but you did not test these use cases. In this case the coverage should be below 100%.
3. The methods are there because a framework demands them. In this case the methods are part of the code that is directly integrated with the framework and should therefore be separated from the rest of the code anyway.
4. like #3, but you can not separate the code, because the framework is stupid. This might be a valid case of suppressing coverage for certain methods, but with such a framework you will probably never reach an acceptable coverage anyway.
5. The case were I feel the pain: toString() implementations for the sole reason of better readability of test failures. These methods are only ever exercised when a test failed. They will never be covered as long as the test suite is green. *shrug*

Answer 3

an even simpler example:

public abstract class A {
    public static int add(int x, int y) {
        return x + y;
    }
}

Here IntelliJ's coverage complains about a not-tested constructor of A. I'd have to write something stupid like

new A() {};

into my test to get it tested. If I use this approach for a helper class

public final class A {
    private A() {}

    public static int add(int x, int y) {
        return x + y;
    }
}

I need to use reflection to "test" the empty code:

final Class<?> clazz = Class.forName("package.name.of.A");
final Constructor<?> constructor = clazz.getDeclaredConstructors()[0];

constructor.setAccessible(true);
constructor.newInstance();

which does not look much smarter.