Java IntelliJ IDEA：忽略代码覆盖率中的琐碎方法

在IntelliJ IDEA 15.0.2中，在测试覆盖率测量过程中，我如何忽略微不足道的getter和setter（微不足道的方法）

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

---

JetBrains告诉我，目前这是不可能的

安德烈·德尔诺夫（IntelliJ）1月6日，22:54

你好，迈克尔

没有忽略特定方法的设置

---

我为此创建了一个示例。

一个更简单的示例：

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

final Class clazz=Class.forName（“package.name.of.A”）；
最终构造函数=clazz.getDeclaredConstructors（）[0]；
constructor.setAccessible（true）；
构造函数。newInstance（）；

---

这看起来不太明智。

仍然没有办法做到这一点，这是一件好事。我理解你的痛苦，我也感觉到了

假设您有一个应用程序，如果没有这些琐碎的setter和getter，它的代码覆盖率将达到100%。这意味着您的所有代码都通过您的测试套件来执行，除了微不足道的setter和getter

这就提出了一个问题，为什么这些琐碎的方法首先会存在。如果您的所有代码都已运行，并且没有调用这些方法，那么您的100%覆盖率是肤浅的。所有代码都已运行，但并非所有用例都已测试。这就是代码覆盖率具有欺骗性的确切原因

有以下几种情况：

这些方法永远不会在任何地方调用，因此应该删除

这些方法在某个地方被调用，但是您没有测试这些用例。在这种情况下，覆盖率应低于100%

这些方法之所以存在，是因为框架需要它们。在这种情况下，方法是与框架直接集成的代码的一部分，因此无论如何都应该与代码的其余部分分离

比如#3，但是你不能把代码分开，因为框架很愚蠢。这可能是抑制某些方法覆盖率的有效案例，但使用这样的框架，您可能永远无法达到可接受的覆盖率

这种情况让我感到痛苦：toString（）实现的唯一原因是测试失败的可读性更好。这些方法仅在测试失败时使用。只要测试套件是绿色的，它们就永远不会被覆盖*耸耸肩*

---

代码覆盖率就是代码覆盖率。要么你运行它，要么你不运行。如果没有覆盖100%的代码，就看不出说您有100%的覆盖率有什么用处。琐碎的getter和setter是自动生成的。为此编写测试是浪费时间。另外，我同意上面的评论。我也同意这样的重新测试是浪费时间。只是认为100%意味着100%。100%的重要代码是另一回事，在我看来更重要。没错。100%就是100%。但是我想知道我是否可以改变它，而不是我是否应该。getter和setter违反了封装。如果您不打算编写高质量的OO代码，那么为什么还要为覆盖率指标而烦恼呢？您的覆盖率很低，因为您正在编写低质量的代码——您的工具告诉您这一点是件好事。您试图对自己和其他人撒谎，说您正在编写比实际质量更高的代码--100%覆盖率！=100%的质量。如果您采用了事件源编码模型，并放弃了贫乏的领域模型方法，那么您将能够自然地达到100%的覆盖率，而不会撒谎。