100%的代码覆盖率没有涵盖我所有的真实案例

Question

我创建了一个应用程序，做了一些单元测试，并接近了100% 代码覆盖。

当在不同的条件下测试应用程序时，应用程序不止一次失败，因此我创建了/增加了当前的测试以涵盖这些可能性，但可能我仍然遗漏了一些情况，而100%的覆盖率并没有显示出来。

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

Answer 1

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

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问题。

Answer 2

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

这也不能证明你有很好的代码。例如，如果您使用的是一个访问文件的类，您可以模拟和测试所有预期的场景，但好的做法是仍然可以捕获意外场景中抛出的任何异常--这会创建不可测试的代码块，如何测试意外情况？

虽然这并不是件坏事，但在我看来，在80%左右的更现实的覆盖范围内，基于多个场景的测试将产生更好的质量。

就个人而言，单元测试更多的是关于锁定功能，以及证明它的工作。我宁愿有50个测试重叠相同的核心代码，也不愿用一个后备存储来证明每个属性。

不幸的是，除了勤奋和有能力的开发之外，我不知道任何补充技术或指标。