如何处理代码覆盖？

Question

前几天，我们在不同开发人员和项目负责人之间进行了艰苦的讨论，讨论了代码覆盖率工具以及相应报告的使用。

• 您是否在项目中使用代码覆盖率，如果是，为什么不呢？
• 代码覆盖率是构建的固定部分还是持续集成 或者你只是不时地使用它？
• 您如何处理从报告中得出的数字？

Answer 1

我们使用代码覆盖率来验证我们在测试工作中没有遗漏大部分内容。一旦达到里程碑，我们就会运行完整的覆盖率报告并花几天时间分析结果，为我们错过的区域添加测试覆盖率。

我们不会在每次构建时运行它，因为我不知道我们会定期对它进行分析以证明这一点。

我们分析大块unhit代码的报告。我们发现这是最有效的用途。在过去，我们会尝试达到特定的代码覆盖率目标，但在某些时候，回报会变得非常小。相反，最好使用代码覆盖作为工具来确保您不会忘记任何事情。

Answer 2

1）是的，我们确实使用代码覆盖

2）是的，它是CI构建的一部分（为什么不是？）

3）重要的部分 - 我们不寻求100％的覆盖率。我们所寻找的是有缺陷/复杂的代码，可以从单元测试中轻松找到，而Devs / Leads将了解系统的精细部分。我们确保这些代码区域的覆盖率良好，并随着时间的推移而增加，而不会因为人们在没有必要的测试的情况下修复更多修复而减少。

Answer 3

代码覆盖率告诉您“漏洞”网络有多大，但它并不能告诉您网络中的漏洞有多大。

使用它作为衡量您的测试工作的指标，但不是绝对指标。

可以编写能够100％覆盖并且根本不测试任何内容的代码。

Answer 4

查看代码覆盖率的方法是查看未涵盖的内容并找出未覆盖的原因。代码覆盖只是告诉我们在单元测试运行时会遇到代码行。它没有告诉我们代码是否正常工作。 100％的代码覆盖率是一个很好的数字，但在中型/大型项目中很难实现。

Answer 5

我喜欢测量任何非平凡项目的代码覆盖率。正如已经提到的那样，尽量不要太过追求实现任意/神奇的百分比。有更好的指标，例如基于复杂性的风险，包/名称空间的覆盖等。

看一下这个样本Clover dashboard的相似想法。

Answer 6

我们在构建中执行它，并且我们看到它不应低于某个值，如85％。 我也做自动十大最大未覆盖方法，知道要开始覆盖什么。

Answer 7

许多转向Agile / XP的团队使用代码覆盖率作为衡量其测试自动化工作投资回报率的间接方式。

我认为它是一个实验 - 有一个假设“如果我们开始编写单元测试，我们的代码覆盖率会提高” - 并且通过CI自动收集相应的观察，在图表中报告等是有意义的

您可以使用结果来检测粗糙点：例如，如果在某个时刻趋向于更多覆盖范围，您可能会停下来询问发生了什么。也许团队在编写相关的测试时遇到了麻烦。

Answer 8

我们使用代码覆盖率来确保我们的测试中没有重大漏洞，并且它会在我们的CI中每晚运行。

由于我们还有一整套的selenium-web测试，它们一直在堆栈中运行，我们还会做一个额外的覆盖技巧：

我们设置运行覆盖率的网络应用程序。然后我们运行硒测试的全自动测试电池。其中一些只是烟雾测试。

当运行完整的测试套件时，我们只需查看覆盖范围并检查代码即可识别可疑的死代码。在处理大型项目时，这非常好，因为在一段时间后你可以拥有大量死代码。

我们实际上并没有任何固定的衡量标准，但它们都设置为使用一两个按键运行。

Answer 9

我们确实使用代码覆盖，它集成在我们的夜间构建中。有几种工具可以分析覆盖率数据，通常是报告

1. 声明范围
2. 分支机构覆盖
3. MC / DC覆盖率

我们预计将达到+ 90％的声明和分支机构覆盖率。另一方面，MC / DC覆盖范围为测试团队提供了更广泛的意义。对于未覆盖的代码，我们希望顺便提出理由记录。

Answer 10

我发现它取决于代码本身。我不会重复Joel在SO播客＃38中的陈述，但结果是“尽量务实”。

代码覆盖率非常适合应用的核心元素。

我将代码视为依赖树，如果叶子工作（例如基本UI或代码调用单元测试DAL）并且我在开发它们时测试它们，或者更新它们，那么有一个很有可能他们会工作，如果有一个错误，那么找到或修复就不难了，所以模拟一些测试所花费的时间可能会浪费时间。是的，有一个问题是对它们所依赖的代码的更新可能会影响它们，但同样，这是一个案例的事情，它们所依赖的代码的单元测试应该覆盖它。

当涉及到代码的中继或分支时，功能的代码覆盖（与每个功能相对）是非常重要的。

例如，我最近在一个团队中构建了一个应用程序，需要一组计算来计算碳排放量。我写了一套测试来测试每一个计算，并且这样做很高兴看到依赖注入模式工作正常。

不可避免地，由于政府行为改变，我们不得不在方程式中添加一个参数，并且所有100多个测试都破裂了。

我意识到要更新它们，除了测试一个错字（我可以测试一次），我是单位/回归测试数学，并最终花时间建立应用程序的另一个区域。

Answer 11

1）是的，我们确实测量了简单的节点覆盖范围，因为：

• 使用我们当前的项目*（Rails网络应用程序）
很容易
• 它鼓励我们的开发人员编写测试（一些来自临时测试的背景）

2）代码覆盖是我们持续集成过程的一部分。

3）报告中的数字用于：

• 强制执行最低级别的覆盖率（95％否则构建失败）
• 找到应该测试的代码部分

系统的某些部分测试并不是那么有用（通常需要使用模拟对象来处理外部系统）。但通常具有良好的覆盖率可以更容易地维护项目。我们知道修复或新功能不会破坏现有功能。

*设置Rails所需覆盖范围的详细信息：Min Limit 95 Ahead