IntelliJ IDEA: игнорировать тривиальные методы в охвате кода

В IntelliJ IDEA 15.0.2 как я могу игнорировать тривиальные геттеры и сеттеры (тривиальные методы) во время измерения тестового покрытия?

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

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

Измерение каждой линии приведет к 75%. Измерение только вышеуказанного метода приведет к 100%. И это 100% кода, полезного для тестирования.

Почему я ничего не нашел об этом в Интернете? Я погружаюсь в плохую практику?

ОБНОВИТЬ

Этот код также подходит для тестирования:

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

Ответ 1

JetBrains сказал мне, что в настоящее время это невозможно.

Андрей Дернов (IntelliJ) 6 янв, 22:54

Привет, Майкл,

Невозможно игнорировать определенный метод.

Я создал для этого проблему.

Ответ 2

До сих пор нет способа сделать это, и это хорошо. Я понимаю твою боль и тоже ее чувствую.

Предположим, у вас есть приложение, которое покрыло бы код на 100%, если бы не эти тривиальные сеттеры и геттеры. Это означает, что весь ваш код выполняется через ваш набор тестов, за исключением тривиальных сеттеров и геттеров.

Это поднимает вопрос, почему тривиальные методы существуют в первую очередь. Если весь ваш код запущен, а методы не вызваны, то ваше 100% покрытие является поверхностным. Весь код выполняется, но не все варианты использования проверены. Это точная причина, по которой покрытие кода обманчиво.

Есть следующие случаи:

Методы никогда нигде не вызываются и поэтому должны быть удалены.
Методы где-то вызываются, но вы не тестировали эти варианты использования. В этом случае охват должен быть ниже 100%.
Методы существуют потому, что их требует структура. В этом случае методы являются частью кода, который непосредственно интегрирован с платформой и поэтому должен быть отделен от остального кода в любом случае.
как # 3, но вы не можете отделить код, потому что рамки глупы. Это может быть допустимым случаем подавления покрытия для определенных методов, но с такой структурой вы, вероятно, никогда не достигнете приемлемого покрытия.
Случай, в котором я чувствую боль: реализации toString() по единственной причине лучшей читаемости неудачных тестов. Эти методы применяются только тогда, когда тест не пройден. Они никогда не будут покрыты, пока набор тестов зеленый. * Пожала плечами *

Ответ 3

еще более простой пример:

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

Здесь освещение IntelliJ жалуется на не проверенный конструктор A. Мне нужно написать что-то глупое, как

new A() {};

в мой тест, чтобы проверить его. Если я использую этот подход для вспомогательного класса

public final class A {
    private A() {}

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

Мне нужно использовать рефлексию для "проверки" пустого кода:

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

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

который выглядит не намного умнее.