如何在带有 if 条件的 for-in 循环中开玩笑地增加分支覆盖率？答案

【问题标题】：How to increase branch coverage in jest in for-in loop with if condition?如何在带有 if 条件的 for-in 循环中开玩笑地增加分支覆盖率？
【发布时间】：2019-11-09 10:26:02
【问题描述】：

我有以下代码，它将几个字段从一个对象映射到另一个对象并复制值：

//Function params
var source= {"f1": "v1", "f2": "v2", "f3":"v3"};
var fieldsMapping = {"f1": "c1", "f2":"c2"};

//function definition starts
var copiedObj = {};    
for (var name in source) {
  if (source.hasOwnProperty(name)) { //Line X
    if(fieldsMapping[name]){
        copiedObj[fieldsMapping[name]] = source[name];
    }
  }
}

console.log(copiedObj); //outputs {c1: "v1", c2: "v2"}

我在jest 中为此函数编写了测试用例，具有100% 的行覆盖率，但未覆盖分支覆盖率显示Line X。根据Standards 类似TSLint，for-in 循环后面应该跟if condition。

任何人都可以建议如何有一个测试用例来为此增加branch coverage 吗？

【问题讨论】：

如果您循环遍历该对象的属性，那该行肯定是多余的吗？
@andymccullough 是的，行是多余的，但如果删除，该函数不符合 TSLint。
公平点，您可以使用性能不高的 Object.keys().forEach()。但是，如果没有任何价值，我不会担心这样的代码覆盖率。每次测试的质量超过数量..

标签： javascript typescript unit-testing jestjs tslint

【解决方案1】：

所以你看这意味着这个if 是为你所有的测试用例执行的。这就是线路覆盖率显示为 100% 的原因。但是要获得 100% 的分支覆盖率，您需要使 if 未针对某些特定测试用例运行。

hasOwnProperty 为从原型继承的属性返回 false。所以我们将使用它来使该行不被执行：

const base = { a: 1};
const source = Object.create(base, {b: 2, c: 3} );
const fieldsMapping = {a: 'aa', b: 'bb', c: 'cc'};

expect(yourFunction(source, fieldsMapping)).toEqual({ bb: 2, cc: 3 });

PS 尽量不要沉迷于 100% 覆盖率目标。

【讨论】：

我同意你的 PS 建议也知道，hasOwnProperty 为继承的属性返回 false，而我的情况并非如此。因此，我正在尝试找到一些解决方案，如果可以解决的话。（可能是一些TSLint 跳过的命令，因为类似的语句出现在许多其他函数中）
抱歉，不明白您的评论（相信是因为 SO 跳过了一些新行）。您是否尝试过放置一些继承的属性，但分支覆盖率仍然是 50%？或者您想让分支覆盖率达到 100%，而不需要对测试进行任何更改？
我想在不更改代码的情况下使分支覆盖率达到 100%。该对象不需要被继承。-我找不到，如果存在任何 TSLint 注释命令，因此可以在该行保持分支覆盖。类似于/* tslink-disable*/

【解决方案2】：

额外的if 是为了代码的健壮性。这种稳健性检查无法以合理的方式进行测试。这也将发生在代码的其他各个部分 - 它经常发生在 switch 语句中，其中明确涵盖了所有可能的情况，并添加了一个额外的默认情况，只是为了引发异常或以其他方式处理这种“不可能”的情况。或者，想想添加到代码中的断言语句：既然断言永远不会失败，严格来说，你永远无法覆盖隐藏在断言语句中的 else 分支——你如何测试断言中的表达式是否适合实际检测到您想要的问题？

删除此类健壮性代码和断言并不是一个好主意，因为它们还可以帮助您检测未来更改的不良副作用。最后，您必须做出明智的决定（通过详细查看覆盖率报告，而不仅仅是总体百分比）您的代码中哪些语句/分支等确实需要被覆盖，哪些不需要。

最后，请注意，高代码覆盖率并不一定表明您的测试套件具有高质量。如果您的测试套件能够检测到代码中可能存在的错误，那么您的测试套件就具有很高的质量。您可以拥有一个覆盖率 100% 且不会检测到任何潜在错误的测试套件。

【讨论】：