棕色域ASP.NET应用程序的有用/现实代码覆盖目标

Question

让我限定这个问题。我正在开发一个“经典”的ASP.NET应用程序（Web窗体），它不使用Model-View-Presenter而且不是使用TDD编写的。它还使用过时的数据访问策略（手写DAO层调用存储过程来填充和持久化对象），尽管我强烈希望这样做，但它不太可能升级到ORM。

自从我接手开发应用程序以来，大多数新功能都是使用TDD实现的。这仍旧旧代码库，DAL层和整个UI未经测试。在我弄清楚应用程序距离神秘的70％代码覆盖率目标有多远之前，我想清楚一下在确定代码覆盖率时通常包含哪种代码。

明确包含业务逻辑代码，但WebForms代码如何？另外，数据访问代码怎么样？如上所述，我们的数据访问层使用存储过程来填充对象图并将它们保存回DB。物体持久性和再水化是否应包括在内？

如果这个问题过于开放，我道歉，我只是觉得有点不知所措并且对如何使这个棕色地块应用程序更好地感到困惑。

谢谢！

Answer 1

不要为代码覆盖率或任何其他代码指标设置目标。通常情况下，硬目标造成的伤害大于良好。

如果您向其他开发者提供硬代码指标目标，如果他们不了解目标的潜在原因，他们将游戏目标。

作为一个平行的例子，你不会相信我在职业生涯中看到过多少“Keep FxCopy happy”代码评论。

如果为测试覆盖设置了硬目标，懒惰的开发人员可能会跳过编写空检查等，因为如果他们没有编写相应的测试，它会减少覆盖范围。最终结果是代码质量较差。

相反，了解TDD优势的开发人员不需要目标，因为无论如何他们都会做正确的事。

这并不意味着代码覆盖率指标无关紧要。这是非常相关的，但我认为你应该制定一条规则，指出绝对不能减少，而不是设定一个目标。

定期测量它并确保它只是上升。这并不妨碍你有自己的个人目标，但不要设定一个硬目标。

Answer 2

代码覆盖率与应用程序稳定性没有高度相关性。错误报告的流入率（以及错误的严重性）确实与应用程序稳定性具有高度相关性。

当我谈论代码覆盖时，我绝对包含所有内容，并假设100％是不现实的。关于这个问题可能有很多不同的意见，所以对我来说似乎很主观。

如果我在你的位置，我会更担心在担心代码覆盖之前建立手动和自动化回归测试库。

Answer 3

在棕地项目中，无论是源代码指标还是测试覆盖率，达到任何绝对阈值都可能不值得。在代码质量方面，最常建议的方法称为the boy scout rule，即让代码（阵营）比您发现的更清晰。这样，代码就会逐渐改进。

在测试中，情况类似。核心功能已经有效地使用了很长时间，因此该区域中的错误概率很低。 Research表明，与系统整体相比，最近的更改的错误概率是其五倍。因此，我建议从最近更改的代码开始。

您可以使用源代码管理系统中的信息来识别更改，例如将最近构建的二进制文件与上一个生产版本进行比较。为了进一步缩小范围，您可以忽略仅源自重构的更改。然后，您可以将测试重点放在这些区域上。这种方法的一个例子在this blog post中勾勒出来。由于该想法与实际测试方法无关，因此它甚至可以结合单元测试和手动回归测试的结果。