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

发布时间：2020-12-16 06:42:37 所属栏目：asp.Net 来源：网络整理

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

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

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

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

我很抱歉,如果这个问题太开放,我只是觉得有点不知所措,并且对如何使这个棕色地块应用程序更好地形成一些困惑.

谢谢！

解决方法

不要为代码覆盖率或任何其他代码度量标准设置目标.通常证明,硬目标造成的伤害大于好处.

如果您为其他开发人员提供硬代码指标目标,那么如果他们不了解目标的潜在原因,他们就会对目标进行游戏.

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

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

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

这并不意味着代码覆盖率指标无关紧要.这是非常相关的,但我认为你应该有一个规则,它必须永远不会减少,而不是设定一个硬目标.

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!