您实际使用哪些技术来改善代码覆盖率？

Question

我经常使用TDD实现100％的图书馆覆盖率，但并非总是如此，并且似乎总有一部分未经测试和未发现的应用程序遗留下来。
然后有一些情况，当你从遗留代码开始，它只有很少的测试和很少的覆盖率。

请说明您的情况是什么，以及至少改进了覆盖范围的工作原理 我假设您在单元测试期间测量覆盖率，但是如果您正在使用其他技术，请说明。

Answer 1

删除代码。

这不是讽刺，但实际上很严重。任何时候我都会看到最少量的代码重复，甚至是我无法执行的代码，我删除了它。这增加了覆盖范围并提高了可维护性。

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

Answer 2

我假设你读“Code covered vs. Code Tested”，对吗？

如该问题所述，

  

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

现在，我使用eclemma，基于EMMA，代码覆盖率工具解释了为什么100％代码并非总是可行：因为 partially covered lines 由于：< / p>

• 隐含分支在同一行。
• 共享构造函数代码。
• 由于最终阻止而产生的隐含分支。
• 隐藏的分支由于隐藏的Class.forName（）。

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

现在，我同意Frank Krueger的回答。一些未覆盖的代码也可能表示需要进行一些重构，包括一些实际删除的代码;）

Answer 3

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

编辑：稍微扩展一下：

• 如果条件覆盖范围未完成，请检查相互依赖的条件。如果它在那里，重构。如果不是，您应该能够扩展您的测试以达到所有条件。
• 如果条件和分支覆盖范围看起来完整但声明覆盖范围不完整，那么您要么写错了条件（例如，当您不想要时总是从子语言中提前返回），或者您有额外的代码可以安全地被移除。

Answer 4

对我所参与的项目影响最大的两件事是：

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

Answer 5

FIT testing改善了我们的代码覆盖率。它很棒，因为它完全不同。

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

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

使用这种方法，我们将代码覆盖率提高了几个百分点。另外一个好处是，这些测试将跨越多个版本：它们将测试遗留代码，然后再测试新代码。从某种意义上说，它们可以作为回归测试。