【问题标题】:Is branch coverage as useful as line coverage?分支覆盖与线路覆盖一样有用吗?
【发布时间】:2016-09-07 05:44:53
【问题描述】:

我的组织强调 80% 的生产线和分支机构覆盖率。我对线路覆盖要求完全没有问题,但是分支覆盖给了我一个问题。

让我们举个例子:

if(decisionA && decisionB)
{
  // path A - do some complex ninja code stuff
}
else
{
  // path B - tell user i can't do anything
}

现在,我写了 2 个案例,第一个覆盖路径 A,第二个覆盖路径 B。这应该给我 100% 的线路覆盖率。但是,这给了我 50% 的分支覆盖率,因为我只覆盖了 (True && True) + (False && False) 而忽略了 (True && False) + (False && True)。

在我看来,decisionA 和decisionB 的值微不足道,几乎不值得测试。但是,我的组织中的一揽子要求现在意味着我必须编写 4 个测试用例而不是 2 个。带上多个 if 和嵌套 if 会变得复杂。

在我看来,是否选择覆盖分支案例似乎应该由开发人员决定,只要他认为重要的逻辑(在 A 部分中的忍者代码的情况下)已被覆盖。

您对此有何看法?您认为可接受的分支机构覆盖率是多少?我对强制执行高分支覆盖率的焦虑是否合理,或者我没有足够强调代码质量?我知道这是一个有点主观的问题,但在这方面肯定已经建立了良好的模式。

【问题讨论】:

    标签: unit-testing code-coverage code-metrics


    【解决方案1】:

    分支覆盖率是比行覆盖率更有用的指标,因为代码格式更改会改变行覆盖率指标的值。

    考虑这两个代码片段,对于条件始终为真的情况:

     If (condition) {
        good();
     } else {
        bad();
     }
    

     If (condition) {good();} else {bad();}
    

    这两种情况的分支覆盖率均为 50%。第二种情况线路覆盖率为100%,第一种情况较少。

    使用行覆盖率作为衡量标准可以鼓励开发人员对其代码格式进行无用的更改,而不是通过简化复杂逻辑来提高质量,并通过添加更多测试用例来提高质量保证。

    【讨论】:

    • 我认为分析器仍然会在内部将其视为多行。很有趣。
    【解决方案2】:

    首先,术语:您所描述的不是分支覆盖,而是"multiple condition coverage" or "compound condition coverage"

    您绝对不想为多条件覆盖设定标准;工作太多,收获太少。例如,如果您的条件是a & b & c & d & e,其中五个基本条件都是布尔值,那么您有 32 个测试要编写,这是不合理的。拍摄基本条件覆盖率会更合理:编写一个测试,所有五个条件都为假,然后每个条件都为真一个测试,总共六个。

    分支覆盖意味着测试通过每个分支执行所有路径,例如ifelse 在您的示例中。在您的示例中,行和分支覆盖均通过两个测试实现;如果没有else 或一行上有多个分支,则分支覆盖率会有所不同。分支覆盖比多(或基本)条件覆盖更容易实现,一些工具对其进行测量,为它设定一个标准而不是线覆盖是合理的。 Raedwald 的观点很好,尽管我通过禁止将决策隐藏在单行中的结构来解决它。

    【讨论】:

    • 实际上,像a & b & ... 这样的表达式只需要在代码使用逻辑 非短路运算符而不是 的情况下覆盖大量测试短路的条件运算符(&&)。在实践中,程序员使用短路测试,需要的测试数量要少得多。例如,给定一个带有a == false 的测试,我们不需要另一个带有b == false 的测试来完全覆盖包含a && b 的表达式。无法使用条件覆盖的真正原因仅仅是现有的代码覆盖工具不支持它。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2015-02-08
    • 1970-01-01
    • 2016-06-21
    • 1970-01-01
    • 1970-01-01
    • 2018-05-16
    • 1970-01-01
    相关资源
    最近更新 更多