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;
}
Источник

4 ответа

Решение

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

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

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

Там нет настройки, чтобы игнорировать определенный метод.

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

Источник

Теперь это возможно, начиная с Intellij Idea 2022.3 теперь можно игнорировать методы, основанные на аннотациях.

      Settings → Build, Execution, Deployment → Coverage

Вы можете указать в настройках, какие аннотации должны означать, что метод игнорируется. Вы можете создать новую аннотацию или использовать существующие аннотации.

Более подробную информацию можно найти в сообщении блога IntelliJ IDEA 2022.3 EAP 2: улучшенный профилировщик IntelliJ, более быстрый запуск IDE и многое другое.

Источник

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

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

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

Возможны следующие случаи:

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

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

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();

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

Источник
Другие вопросы по тегам