100％的代码覆盖率并未涵盖我的所有实际案例

Question

我创建了app，做了一些unit tests并接近100％code coverage。

在不同的条件，配置等测试应用程序时，应用程序失败了不止一次，因此我创建/增加了当前的测试以涵盖这些可能性，但可能我仍然遗漏了一些情况，100％覆盖率揭露。

正因为如此，我想知道是否有一种方法或技术可以补充或帮助涵盖所有可能的排列/案例，并在此基础上创建更好的单元测试和代码覆盖。

Answer 1

增加代码覆盖率可以提高您对代码正确性的信心，但即使所有代码路径都被测试覆盖，覆盖 所有可能的输入 <通常也是不切实际的/ strong>也是。例如，采用这种方法：

public static int divide(int numerator, int denominator) {
    return numerator / denominator;
}

您可以轻松编写一个涵盖此方法100％的单元测试：

@Test
public void testDivide() {
    assertEquals(2, MathHelper.divide(4, 2));
}

但是在分母= 0的情况下，你仍会有一个除以零的错误。

你能做的最好的事情就是尽可能地考虑尽可能多的有趣的边缘情况输入并围绕它们编写测试。当你遇到有新颖输入的bug时，修复bug并编写新的测试（如你所做的那样）以防止回归。

考虑代码库和/或代码的外部依赖性可能出现的问题通常也会有所帮助，这些代码具有许多代码路径，而这些代码路径并未显示在仅测量代码库的代码覆盖率指标中。数据库不可用时会发生什么？网络不可用？磁盘已满？等

有关如何更好地思考有趣边缘案例的一些有用提示，请参阅此Quora question。

Answer 2

100％的代码覆盖率证明您的所有代码都在单元测试中执行。它并不意味着事情可能出错。

它也没有证明你有很好的代码。例如，如果您使用的是访问文件的类，则可以模拟并测试所有预期的方案，但是良好的做法是仍然可以捕获在意外情况下抛出的任何异常 - 这会创建不可测试的代码块，您如何测试意外？

虽然不是一件坏事，但是在我看来，80％以上的更实际的覆盖范围，但是基于多个场景的测试会产生更好的质量。

就个人而言，单元测试与锁定功能同样重要，因为它证明了它的工作原理。我很快就会有50个测试重叠相同的核心代码，而不是通过后备存储来证明每个属性。

不幸的是，除了勤奋和称职的发展之外，我不知道任何补充技巧或指标。