Question

在提出这个问题之前，我先阅读了这些问题及其答案：

并阅读其他博客，例如Martin Fowler - TestCoverage。

我的结论 - 当然是简历 - 社区说：

不浪费时间，在时间就是金钱的情况下，创建测试只是为了获得100％的代码覆盖率。
也许像80％或90％的红外线测试这样的神奇数字可以覆盖99.99999％的功能。那么，为什么你想浪费时间来完成0.000001％的功能？！

我同意。但我担心给开发人员提供不创建测试的机会，因为他认为这并不重要。我知道我们可以通过让其他人在发布之前验证代码来避免这些错误。

问题

以控制开发人员知道不应该测试的内容的方式进行思考，在开发人员明确标记的代码中创建一种//special comment将是一个很好的做法，他知道它不会值得测试？或者这是一个无关紧要的信息，搞乱了代码？有人可以提出另一个想法来实现它吗？

在阅读这个问题的任何答案之前，我认为这是一个很好的做法，因为第三个人可以检查，同意或不同意，为什么开发人员不会覆盖该代码。

java示例：

public String encodeToUTF8(String value){
    String encodedValue = null;

    try {
        encodedValue = URLEncoder.encode(value, "UTF-8");
    }
    catch (UnsupportedEncodingException ignore) {
        // [coverage-not-need] this exception will never occur because UTF-8 is a supported encoding type
    }
    return encodedValue;
}

术语：100％代码覆盖率意味着涵盖所有分支，而不仅仅是所有分支。

Answer 1

大多数覆盖工具都具有这一特殊注释，您可以声明此代码不具有覆盖范围。例如，Perl的Devel::Cover uses # uncoverable和Ruby＆＃39; simplecov has # :nocov:

但是，我会提醒开发人员过早地宣布无法解决的事情，或过于依赖它。编写代码的开发人员可能对测试机会视而不见。和任何评论一样，如果周围的代码发生变化，它可能会过时。使用太多，它会给你的测试覆盖率带来一种错误的信心。

在您完成测试，运行覆盖范围并确定该语句确实几乎无法测试之后，将其作为最后的手段。同样，我提醒我不要以此为借口来解决那些难以测试的事情。通常这表明需要重新设计而不是真正不可测试的代码。

您的示例代码是滥用＆＃34;不可移动＆＃34;的完美案例。码。如果异常永远不会发生，我不得不想知道为什么那里会有一个阻塞块。如果发生了，那么它将被静音，用户将会想知道为什么他们在代码中稍后会在某处获得NullPointerException。相反，应该没有try/catch块。应该允许异常在编码失败的例外情况中抛出错误。

public String encodeToUTF8(String value){
    return URLEncoder.encode(value, "UTF-8");
}

我不是Java程序员，但我知道它不喜欢未经检查的异常。如果Java要求你捕获所有可能的异常（呃）catch应该断言或重新抛出;不会使异常沉默的东西。

这就是为什么你要使用＆＃34;不可接受的＆＃34;标记非常，非常谨慎，只有经过仔细审查。检查未覆盖的代码通常会导致发现隐藏的错误或设计不良的代码。

如何确保开发人员知道测试不重要的内容？

问题

1 个答案: