Java 在IntelliJ IDEA中，如何从覆盖率度量中排除源代码？

在一个项目中，我有一个实用程序类，如下所示：

public final class Util {
    private Util() {}
    public static String method1(InputStream in) {...}
    public static String method2(BufferedReader in) {...}
    public static String method3(File file) {...}
}

该类是一个实用类，因为它只包含

静态方法。
因此，它被声明为
final
，其构造函数是
private。
创建实例或派生子类根本没有任何意义

我有一套测试项目的单元测试。
我正在使用IntelliJ IDEA运行测试，测量并可视化代码覆盖率。
实用工具
类Util
的构造函数现在降低了覆盖率。
我希望看到100%对100%的逻辑覆盖率。
像实用程序类的私有构造函数这样的代码降低了覆盖率

是否有可能（最好是通过注释）将方法或构造函数标记为与代码覆盖率无关，以便将此类代码从覆盖率报告中排除，从而获得100%的覆盖率？

我知道，在一般情况下，从覆盖率报告中隐藏代码是对您自己不利的。我不介意报告中是否有一个“被忽略的项目”的列表——事实上，这很好，可以检查是否有人忽略了不应该被忽略的东西。关键是关于覆盖率没有意义的代码，比如实用程序类的私有构造函数

我试图找到
annotations.jar
是否包含候选项。唯一一个看起来似乎可以远程完成的注释是
TestOnly
，但它并没有达到这个目的。
我还在
plugins/coverage/lib/*.jar
中四处搜索，没有找到合适的人选，但也许我错过了

更新
这个问题现在已经过时了。与此同时，IntelliJ IDEA和Jacoco学会了如何忽略没有呼叫者的私有构造函数的覆盖范围。我不知道Java中有任何其他故意无法访问的代码会引发从覆盖率报告中排除的对话。
我对实用程序类使用
enum
，大多数覆盖率工具都知道忽略它的方法

public enum Util { ;

enum
默认情况下是
final
和
private
构造函数。
这个问题现在已经超过一年了；然而，我认为我可以提供一种替代方法，在单元测试中忽略私有构造函数。虽然不太可能，但可以绕过Java中的私有构造函数。此外，它可能在将来修改类，有人可以添加构造函数等。。。有一个单元测试来验证这一点可能会觉得多余，但它确实增加了另一个层次的意图。失败的单元测试肯定会引起我的注意，“我导致了单元测试失败，我确定我知道我在这里改变了什么吗？”

下面是一些示例代码

这里我们有一个带有私有构造函数的类

public final class ClassWithPrivateCtor
{
  private ClassWithPrivateCtor()
  {
    throw new AssertionError(String.format(
      "Illegal instantiation of class: %s.",
      this.getClass().getName()));
  }
}

这是在Java中调用私有构造函数的一种方法

private static <T> void invokePrivateConstructor(final Class<T> type)
  throws Throwable
{
  final Constructor<T> constructor = type.getDeclaredConstructor();

  constructor.setAccessible(true);

  try
  {
    constructor.newInstance();
  }
  catch (InvocationTargetException ex)
  {
    throw ex.getTargetException();
  }
}

我养成了这样验证私有构造函数的习惯，只是为了弄清楚类的原意，无论是实用类还是带有常量的类等等。
我已经尝试过了，它是有效的！我还尝试使用
接口
，但这仅在没有
私有静态
方法的情况下有效。在目前的情况下，这对我很有帮助。我仍然希望有一个更通用的解决方案。你可以添加虚拟测试或嵌套类来调用私有方法，以获得100%的成功。你是对的，我可以，但这也是我想要避免的。你可以编写一个方法来调用一个类中所有有注释的方法。同时，JetBrains甚至实现了“实用程序类应该是枚举”作为检查。他们真好。：）你似乎对报道的理解有误。未涵盖的代码可能被解释为需要更多的测试，也可能被视为代码气味的迹象。在这种情况下，这是一种气味——你真的应该避免像这样的实用程序类，它很可能是一个糟糕设计的产物，你应该尝试修复它，而不是游戏你的覆盖率报告。像这样的游戏报告是metrics程序的最大问题之一，如果你在我的团队中，我们会讨论你认为你现在在做什么。对于不知道真正的代码的人，我认为你使用的是非常强大和教条的语言。我同意公用事业类可能是一种气味，应该提醒人们注意它们。但仅仅因为某些事情经常是坏的，并不意味着它总是坏的。不管怎样，按照Peter Lawrey的建议，现在就使用
enum
。这非常有意义，因为这是一个具有预定义（空）实例集的类，覆盖率现在很好。附言：很高兴在你的团队里有这样的谈话。我不会再为宣扬清白的准则感到孤独。
@Test(
  description = "Verify ClassWithPrivateCtor private constructor fails.",
  expectedExceptions = AssertionError.class)
public void classWithPrivateCtorTest()
  throws Throwable
{
  invokePrivateConstructor(ClassWithPrivateCtor.class);
}