棕地 ASP.NET 应用程序的有用/现实的代码覆盖率目标
让我来限定一下这个问题。我正在开发一个“经典”ASP.NET 应用程序（Web 表单），它不使用模型-视图-演示器，也不是使用 TDD 编写的。它还使用过时的数据访问策略（手写的 DAO 层，调用存储过程来填充和持久化对象），尽管我强烈希望升级到 ORM，但它不太可能升级。
自从我接手该应用程序的开发以来，大多数新功能都是使用 TDD 实现的。旧的代码库、DAL 层和整个 UI 仍然未经测试。在弄清楚应用程序距离神秘的 70% 代码覆盖率目标还有多远之前，我想弄清楚在确定代码覆盖率时通常包含哪些类型的代码。
显然包含了业务逻辑代码，但是WebForms代码呢？另外，数据访问代码怎么样？如上所述，我们的数据访问层使用存储过程来填充对象图并将它们保存回数据库。对象持久性和重新水化是否应该包括在内？
如果这个问题过于开放式，我深表歉意，我只是对如何使这个棕地应用程序处于更好的状态感到有点不知所措和困惑。
谢谢！
Let me qualify this question. I'm working on a "classic" ASP.NET application (Web Forms) that doesn't use Model-View-Presenter and was not written using TDD. It's also using an antiquated data access strategy (hand written DAO layer that invokes stored procs to populate and persist objects) that is unlikely to be upgraded to an ORM despite my strong desire to do so.
Since I took over development of the application, most new features have been implemented using TDD. That still leaves the old code base, DAL layer and entire UI as untested. Before I figure out how far away the application is from that mystical 70% code coverage goal, I'd like to get clarity around what kind of code is typically included when determining code coverage.
Business logic code is clearly included, but how about WebForms code? Additionally, how about data access code? As mentioned above, our data access layer uses stored procedures to populate object graphs and persist them back to a DB. Is object persistence and re-hydration something that should be included?
I apologize if this question is too open ended, I just feel a little overwhelmed and confused about how to get this brownfield application in better shape.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不要为代码覆盖率或任何其他代码指标设置目标。通常情况下，硬目标造成的伤害大于好处。
如果您为其他开发人员提供硬编码指标目标，如果他们不了解该目标的根本原因，他们只会欺骗目标。
作为一个平行的例子，您不会相信我在职业生涯中见过多少“让 FxCopy 开心”的代码注释。
如果您为测试覆盖率设置了硬目标，那么懒惰的开发人员可能会跳过编写空检查等，因为如果他们不编写相应的测试，就会降低他们的覆盖率。最终结果是代码质量较差。
相反，了解 TDD 好处的开发人员不需要目标，因为无论如何他们都会做正确的事情。
这并不意味着代码覆盖率指标不相关。它非常相关，但我认为你不应该设定一个硬性目标，而应该制定一条规则，即它绝不能减少。
因此，定期测量并确保它只会上升。这并不妨碍您拥有自己的个人目标，但不要设定硬性目标。
Don't set targets for code coverage or any other code metrics. It usually turns out that hard targets do more damage than good.
If you give other developers hard code metric targets they will just game the targets if they don't understand the underlying reasons for the target.
As a parallel example, you will not believe how many "Keep FxCopy happy" code comments I've seen in my career.
If you set a hard target for test coverage, lazy developers may skip writing null checks etc. because it decreases their coverage if they don't write the corresponding tests. The end result is poorer code quality.
Conversely, developers who understand the benefits of TDD don't need the target because they'll do the right thing regardless.
That doesn't mean that the code coverage metric is irrelevant. It is very relevant, but instead of setting a hard target, I think you should have a rule that says that it must never decrease.
So measure it regularly and make sure it's only going up. That doesn't preclude you from having your own personal goal, but don't set a hard target.
代码覆盖率与应用程序稳定性没有很高的相关性。错误报告的涌入率（以及错误的严重程度）确实与应用程序的稳定性有很高的相关性。
当我谈论代码覆盖率时，我涵盖了所有内容，只是假设 100% 是不现实的。关于这个问题可能有很多不同的观点，所以对我来说这似乎很主观。
如果我处于您的位置，我会更担心在担心代码覆盖率之前建立手动和自动回归测试库。
Code coverage doesn't have a high correlation to application stability. Rate of influx of bug reports (and the bug's severity) does have a high correlation to application stability.
When I talk about code coverage, I include absolutely everything and just assume 100% is unrealistic. There are probably many different opinions on the subject, so it seems pretty subjective to me.
If I was in your position, I would be more worried about getting manual and automated regression test bases built before worrying about code coverage.
在棕地项目中，可能不值得付出努力来达到任何绝对阈值，无论是源代码指标还是测试覆盖率。在代码质量方面，最建议的方法是童子军规则，即让代码（营地）比你发现的更干净一些。这样，代码就会逐渐完善。
在测试中，情况类似。核心功能已经高效使用了很长时间，因此该区域出现错误的可能性很低。 研究表明，与整个系统相比，最近的更改的错误概率是其五倍。因此，我建议从最近更改的代码开始。
您可以使用源代码管理系统中的信息来识别更改，或者例如将最近构建的二进制文件与最新的生产版本进行比较。为了进一步缩小范围，您可以忽略仅源自重构的更改。然后您可以将测试集中在这些领域。 此博文<中概述了此方法的示例< /a>.由于这个想法与实际的测试方法无关，它甚至可以结合单元测试和手动回归测试的结果。
In brownfield projects, it may not be worth the effort to to reach any absolute threshold, neither for source code metrics, nor for test coverage. In code quality, the most suggested approach is known as the boy scout rule, i.e. leave the code (the camp) a little cleaner than you found it. This way, the code will gradually improve.
In testing, the situation is similar. Core functionality has been used productively for a long time, so there is a low probability for bugs in this area. Research has shown that recent changes have five times the bug probability compared to the system as a whole. Therefore I suggest starting with recently changed code.
You can use information from the source code management system to identify changes, or e.g. compare the most recently built binaries with the last production release. In order to further narrow down the scope, you may ignore changes that solely originate from refactoring. You can then focus your tests on these areas. An example for this approach is sketched in this blog post. Since the idea is agnostic of the actual test methodology, it can even combine results from unit tests and manual regression tests.