让我限定这个问题。我正在开发一个“经典”的 ASP.NET 应用程序(Web 窗体)，它不使用 Model-View-Presenter 并且不是使用 TDD 编写的。它还使用过时的数据访问策略(调用存储过程来填充和持久化对象的手写 DAO 层)，尽管我强烈希望这样做，但不太可能升级到 ORM。
自从我接手开发应用程序以来，大多数新功能都是使用 TDD 实现的。这仍然使旧的代码库、DAL 层和整个 UI 未经测试。在弄清楚应用程序离神秘的 70% 代码覆盖率目标还有多远之前，我想弄清楚在确定代码覆盖率时通常包含哪些类型的代码。
业务逻辑代码显然包含在内，但是 WebForms 代码呢？另外，数据访问代码怎么样？如上所述，我们的数据访问层使用存储过程来填充对象图并将它们保存回数据库。对象持久性和再水化是否应该包括在内？
如果这个问题过于开放，我深表歉意，我只是对如何使这个棕地应用程序处于更好的状态感到有些不知所措和困惑。
谢谢!
最佳答案
不要设定目标 代码覆盖率或任何其他代码指标。结果通常是 硬目标造成的伤害大于好处 .
如果您给其他开发人员硬编码指标目标，他们只会游戏目标如果他们不了解目标的根本原因。
作为一个平行的例子，你不会相信我在我的职业生涯中看到了多少“让 FxCopy 开心”的代码注释。
如果您为测试覆盖率设置了硬目标，那么懒惰的开发人员可能会跳过编写空检查等，因为如果他们不编写相应的测试，则会降低他们的覆盖率。最终结果是代码质量较差。
相反，了解 TDD 好处的开发人员不需要目标，因为无论如何他们都会做正确的事情。
这并不意味着代码覆盖率指标无关紧要。这是非常相关的，但与其设定一个硬性目标，我认为你应该有一个规则，说明 它绝不能减少 .
所以定期测量它并确保它只会上升。这并不妨碍你有自己的个人目标，但不要设定一个硬目标。
关于asp.net - 棕地 ASP.NET 应用程序的有用/现实的代码覆盖率目标，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2051098/