我创建了一个app，做了一些unit tests 并接近了100% code coverage。
在不同的条件、配置等条件下测试应用程序时。应用程序多次失败，因此我创建/增加了当前测试以涵盖这些可能性，但可能我仍然遗漏了一些情况，即 100% 覆盖率没有不透露。
因此，我想知道是否有一种方法或技术可以补充或帮助覆盖所有可能的排列/案例，并在此基础上创建更好的单元测试和代码覆盖率。
【问题讨论】：
标签： unit-testing code-coverage
增加代码覆盖率可以提高您对代码正确性的信心，但即使所有代码路径都被测试覆盖，覆盖所有可能的输入通常也是不切实际的.以这个方法为例：
public static int divide(int numerator, int denominator) {
return numerator / denominator;
}
您可以轻松编写一个覆盖此方法 100% 行的单元测试：
@Test
public void testDivide() {
assertEquals(2, MathHelper.divide(4, 2));
}
但在分母 = 0 的情况下，您仍然会出现除以零错误。
您能做的最好的事情就是尽可能多地考虑有趣的边缘案例输入，并围绕它们编写测试。当您确实遇到具有新输入的错误时，请修复错误并编写新测试（就像您所做的那样）以防止回归。
考虑库和/或代码的外部依赖项可能出现的问题通常也很有帮助，它们有许多自己的代码路径，这些路径没有显示在仅衡量代码库的代码覆盖率指标中。当数据库不可用时会发生什么？网络不可用？磁盘已满？等等
有关如何更好地思考有趣的边缘案例的一些有用提示，请参阅Quora question。
【讨论】：
100% 的代码覆盖率证明您的所有代码都在单元测试中执行。这并不意味着事情不会出错。
这也不能证明你有好的代码。例如，如果您正在使用一个访问文件的类，您可以模拟和测试所有预期的场景，但好的做法是仍然有一些东西来捕获在意外场景中抛出的任何异常——这会创建不可测试的代码块，你如何测试意外？
虽然不是一件坏事，但在我看来，更真实的覆盖率约为 80%，但基于多个场景的测试将产生更好的质量。
就个人而言，单元测试既要锁定功能，又要证明其有效。我宁愿让 50 个测试重叠相同的核心代码，也不愿用后备存储证明每个属性。
不幸的是，除了勤奋和有能力的开发之外，我不知道任何补充技术或指标。
【讨论】：