language-agnostic - 您实际成功地使用了哪些技术来提高代码覆盖率？

Question

我经常使用 TDD 实现 100% 的库覆盖率，但并非总是如此，而且似乎总是有部分应用程序未测试和未发现。
然后有些情况下，您从测试很少且覆盖率很少的遗留代码开始。

请说出您的情况以及至少改善了覆盖范围的有效方法。
我假设您在单元测试期间测量覆盖率，但如果您正在使用其他技术。

Answer 1

删除代码。

这并不刻薄，但实际上很严重。每当我看到最少量的代码重复甚至无法执行的代码时，我都会将其删除。这增加了覆盖范围并提高了可维护性。

我应该注意到，这更适用于增加旧代码库与新代码库的覆盖率。

Answer 2

我假设你读过“代码覆盖与代码测试”，对吧？

如该问题所述，

即使有 100% 的块覆盖率 + 100% 的弧线覆盖率 + 100% 无错误的至少一条路径直线代码，仍然会有输入数据以表现出更多错误的方式执行路径/循环。

现在，我使用基于 EMMA 的eclemma ，该代码覆盖工具解释了为什么 100% 代码并不总是可能的：因为部分覆盖的行是由于：

• 同一行上的隐式分支。
• 共享构造函数代码。
• 由于 finally 块的隐式分支。
• 由于隐藏的 Class.forName() 导致的隐式分支。

因此，所有这 4 种情况都可能是重构的良好候选者，从而导致更好的代码覆盖率。

现在，我同意弗兰克克鲁格的回答。一些未涵盖的代码也可能表明要进行一些重构，包括一些要实际删除的代码；）

Answer 3

我们使用 Perl，所以Devel::Cover对我们非常有用。在单元测试期间显示每个语句的覆盖率、分支覆盖率和条件覆盖率，以及 POD 覆盖率等内容。我们使用易于识别的 HTML 输出，绿色表示“100%”，黄色和红色表示较低的覆盖率。

编辑：稍微扩展一下：

• 如果条件覆盖不完整，请检查相互依赖的条件。如果存在，请重构。如果不是，您应该能够扩展您的测试以达到所有条件。
• 如果条件和分支覆盖看起来完整但语句覆盖不完整，那么您要么写错了条件（例如，总是在您不打算这样做时从子程序中提前返回），或者您有可以安全删除的额外代码.

Answer 4

对我从事的项目影响最大的两件事是：

1. 定期“提醒”开发团队实际实施单元测试，并审查如何编写有效的测试。
2. 生成整体测试覆盖率报告，并在开发经理之间传播。

Answer 5

FIT 测试提高了我们的代码覆盖率。这很棒，因为它是一种完全不同的策略。

背景：我们混合了旧代码和新代码。我们尝试尽可能多地对新内容进行单元/集成测试，但是因为我们正在迁移到 Hibernate/Postgres 并且远离 OODB，所以测试遗留代码没有多大意义。

对于那些不知道的人，FIT 是一种从用户角度测试软件的方法。本质上，您可以在 HTML 表格中指定所需的行为：表格指定针对软件的操作和所需的结果。我们的团队编写“粘合代码”（又名 FIT 测试），将操作映射到针对代码的调用。请注意，与单元测试相比，这些测试在“从空间”的视图中运行。

使用这种方法，我们将代码覆盖率提高了几个百分点。另一个好处是这些测试将跨版本进行桥接：它们将测试旧代码，然后再测试新代码。即，在某种意义上，它们用作回归测试。