有没有专门测量有用代码覆盖率的工具？答案

【问题标题】：Are there any tools which specifically measure useful code coverage?有没有专门测量有用代码覆盖率的工具？
【发布时间】：2011-12-14 11:35:37
【问题描述】：

虽然会适得其反，但可以编写一个执行某些代码并断言真实的单元测试。这是一个故意极端且简化的示例 - 我相信大多数人都遇到过执行代码而不实际使用它的测试。

是否有任何代码覆盖工具可以评估被覆盖的代码是否实际用作测试断言的一部分？

【问题讨论】：

可能重复：stackoverflow.com/questions/170297/code-covered-vs-code-tested
预防而不是检测到这一点不是更好吗？（评论，教育）
@Gishu 是的，但是在您引入测试的复杂代码库中，审阅者发现这个问题的机会很小 - 因此无法触发教育。

标签： unit-testing tdd code-coverage

【解决方案1】：

您本质上想要的是计算覆盖代码与覆盖测试中断言的 backward code slice（减去单元测试本身）之间的交集。

如果该交集为空，则断言不会测试应用程序的任何部分。

大多数代码覆盖率工具不计算切片，所以我猜你的问题的答案是“否”。

【讨论】：

即便如此，我想如果我理解正确的话，它只会告诉你一些额外的代码被覆盖了，而不是你想要的代码被覆盖了。
它会告诉一些应用程序代码被覆盖，正如将值提供给断言的代码所证明的那样。它无法告诉您“预期的”代码已被覆盖；它显然无法读懂你的想法。
我就是这么想的。我想这是 TDD 实践可能有助于您编写测试 => 红色 => 编写代码 => 绿色的地方。然后你觉得你写的代码一定已经过测试，但是一旦你超越了那个循环，你可以添加/删除其他代码并使测试通过，你可能会再次发现代码。您的测试只是指定您希望代码做什么的意图，而不是它如何进行 - 这是一个棘手的问题，也是一种可能导致脆弱测试的方法。
意图并不重要，如果你有一个可视化工具可以显示哪些代码被 Assert 语句覆盖。我最近一直在使用 DotCover，它引导我朝这个方向思考。这对于指示测试的正交性也很有用 - 其中代码被多个断言语句覆盖。
但是一个断言可能实际上并没有覆盖代码——它可能正在测试一个模拟期望或者读取一个由之前的代码准备好的简单属性。我倾向于遵循安排/行动/断言模式，其中我的“断言”正在测试我的“行动”是否根据我在“安排”中设置的内容做了我想要的 - 有时行动/断言会变成一个，但这只是用于简单测试。您可能会尝试通过测试进行覆盖，但很难区分测试安排覆盖的代码（除非在某些可以跟踪的测试设置中）和由操作和断言测试完成的代码。

【解决方案2】：

你需要某种依赖分析，即找出断言依赖于哪些语句。然后，这必须与覆盖范围进行交叉检查。 CodeSurfer 是一种对 C 进行依赖性分析的商业工具。

【讨论】：

你可以这么说。某些代码是否被用作断言的端口是依赖分析。某些代码是否被测试执行是覆盖收集。我认为你的问题是这两者的结合。为了轻松收集 C 的覆盖率，您始终可以使用 gcc 套件中的 gcov 分析器。
关于每个测试的覆盖率还有其他 SO 问题，但这需要您运行每个测试并比较覆盖率 - 但它只会告诉您覆盖了某些内容，而不是预期的代码位实际上覆盖。我认为这是一种危险的心态，我相信，在经过几年的 TDD 之后，测试应该指定代码做什么的意图，而不是它的执行方式——当您过度分析覆盖结果时，可能会发生这种情况。

【解决方案3】：

再一次，我只是调查一下为什么会发生这种情况？仅仅为了增加覆盖率而添加的测试通常是更严重原因的症状。教育每个人而不是挑选特定的罪犯通常效果更好。

识别已经犯过的错误：您可以使用静态代码分析工具来检查该错误

每个测试至少有一个断言。当然，这也可以被流氓断言打败。
没有未使用的返回值。

我在 RoyOsherove 的名为 TestLint 的东西中看到了第一个，第二个我可以想到 Parasoft 或类似的东西。这仍然不是一个万无一失的方法，并且会花费大量时间来研究 SCA 报告的问题。但这是我能想到的最好的了。

【讨论】：

我没有任何证据表明这种情况正在发生 - 我只是怀疑它是我工作的地方。我故意以与语言/工具链无关的方式问这个问题，因为我更感兴趣的是它是否已经完成而不是使用它。由于这家公司的监控错误，为了覆盖目的而添加了测试——但我怀疑这很常见。