James Shore：不要使用单元测试的代码覆盖率

如果您正在使用测试驱动开发，请不要衡量单元测试的代码覆盖率，这比无用的统计更糟糕; 它会积极地引导你误入歧途。
你应该怎么做？这取决于你想要完成什么。

改进代码和测试实践
如果您正在尝试改进团队的编码和测试实践，请执行转义缺陷的根本原因分析1，然后改进您的设计和流程，以防止再次发生此类缺陷。
如果等待缺陷逃逸对您来说风险太大，那么经验丰富的QA测试人员会进行探索性测试并对结果进行根本原因分析，无论哪种方式，这里的想法是分析您的Bug，以了解要改进的内容，代码覆盖率不会告诉您。

提高程序员代码质量
如果您正在尝试提高程序员的代码质量，教授测试技能，加快测试循环，重构更多，使用进化设计，并尝试结对编程或mob编程。
教授测试技能并加快测试循环，使程序员更容易编写有价值的测试。测试覆盖范围不会做到的， 它只是鼓励编写毫无价值的测试来使数字上升。
重构更多并使用进化设计使您的设计更简单，更易于理解。这减少了与设计相关的缺陷。
结对编程或mob编程可以增强团队的自律能力，每个人偶尔都会感到懒惰，但是当你结对编程或mob编程时，所涉及的每个人只会在同一时间变得懒惰。它还使您的代码质量更高，更易于理解，因为协同工作可以让程序员看到彼此代码中的弱点，并提出更优雅的解决方案。

改善测试纪律
有些人使用代码覆盖率指标来强化他们想要的习惯。不幸的是，习惯不能强制执行，只能培养。我想起了一个我工作的地方，管理者想要好的代码提交日志。他们配置了他们的工具来对每次提交强制执行注释。他们最常见的评论是啥？“a” ，后来他们更改了工具，以便在每次提交时强制执行多字注释。现在最常见的评论是“aa a”。
执法不会改变思想。相反，使用辅导和学科增强实践，如结对编程或mob编程。

提高要求代码质量
如果您正在努力改善代码满足客户需求的程度，请尽早让客户代表参与进来，例如在“早期Sprint结束之前”。他们不会总是立刻告诉你你错过了什么，但是你越早给他们机会这样做，你就越有可能学到你需要知道的东西。

提高非功能性质量
如果您正在尝试提高可靠性或性能等“非功能”特性，请使用实际监控，使用故障快速代码和专用测试平台。非功能属性作为一个整体从系统中出现，因此即使是覆盖率为100％的代码库也会出现问题。

这是关于TDD的事情
TDD的定义是，如果没有失败的测试，您就不会编写代码，而是在一次覆盖一个分支的紧密循环中执行此操作。所以，如果你正在做TDD，你的任何代码要覆盖是依据事实覆盖。如果你仍然有缺陷，那么别的东西就错了。
如果人们不知道如何正确地进行TDD，代码覆盖率指标将无济于事。如果他们不想覆盖他们的代码，代码覆盖率指标将无济于事。如果出现其他问题，您就明白了，代码覆盖率指标无济于事。他们充其量只是一种分心，而且是最糟糕的游戏指标。找出你真正想要改进的内容并直接关注它。

​​​​​​​PS:Ryan Norris 在Twitter上有一个很棒的故事，关于代码覆盖如何帮助他的团队扭转遗留代码库。Martin Fowler 写过关于偶尔的代码覆盖率审查是如何有用的健全性检查。