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;
}

Araarab

Code coverage is code coverage. Either you run it or you don't. Can't see the usefulness of saying you have 100% coverage if you don't cover 100% of the code. – Dispersive

Trivial getters and setters are autogenerated. Writing tests for that is imho a waste of time. Also see https://mcmap.net/q/135977/-should-unit-tests-be-written-for-getter-and-setters – Araarab

I agree with top comment on top answer there. I also agree RE tests like that are a waste of time. Just opining that 100% means 100%. 100% of the important code is a different thing and more important IMO. – Dispersive

True that. 100% is 100%. However I want to find out if I can change that, not if I should. – Araarab

Getters and setters are violations of encapsulation. If you're not going to write high-quality OO code why bother with your coverage metrics? Your coverage is low because you're writing low-quality code -- it is a good thing that your tool is telling you this. What you're trying to do is lie to yourself and everyone else that you're writing higher-quality code than you actually are -- 100% coverage != 100% quality. If you adopted an event-source model of coding and abandoned your anaemic domain-model approach then you would be able to reach 100% coverage naturally without lying about it. – Seafaring

@SoftwareEngineer "having getters and setters is a code smell" was the hot take of 2015 – Novia

I don't even know what you mean by that – Seafaring

Answer 1

Now it is possible, starting with Intellij Idea 2022.3 it is now possible to ignore methods based on annotations.

Settings → Build, Execution, Deployment → Coverage

You can define in settings which annotations should mean that method is ignored. You can create a new annotation or use existing annotations.

More details can be found in blog post IntelliJ IDEA 2022.3 EAP 2: Improved IntelliJ Profiler, Faster IDE Startup, and More

Delacroix

Answer 2

Update: It's now possible.

---

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.

Araarab

Answer 3

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*

Scarce

Answer 4

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.

Regine