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

19-02-03 banq
                   

如果您正在使用测试驱动开发,请不要衡量单元测试的代码覆盖率,这比无用的统计更糟糕; 它会积极地引导你误入歧途。

你应该怎么做?这取决于你想要完成什么。

改进代码和测试实践

如果您正在尝试改进团队的编码和测试实践,请执行转义缺陷的根本原因分析1,然后改进您的设计和流程,以防止再次发生此类缺陷。

如果等待缺陷逃逸对您来说风险太大,那么经验丰富的QA测试人员会进行探索性测试并对结果进行根本原因分析,无论哪种方式,这里的想法是分析您的Bug,以了解要改进的内容,代码覆盖率不会告诉您。

提高程序员代码质量

如果您正在尝试提高程序员的代码质量,教授测试技能,加快测试循环,重构更多,使用进化设计,并尝试结对编程或mob编程。

教授测试技能并加快测试循环,使程序员更容易编写有价值的测试。测试覆盖范围不会做到的, 它只是鼓励编写毫无价值的测试来使数字上升。

重构更多并使用进化设计使您的设计更简单,更易于理解。这减少了与设计相关的缺陷。

结对编程或mob编程可以增强团队的自律能力,每个人偶尔都会感到懒惰,但是当你结对编程或mob编程时,所涉及的每个人只会在同一时间变得懒惰。它还使您的代码质量更高,更易于理解,因为协同工作可以让程序员看到彼此代码中的弱点,并提出更优雅的解决方案。

改善测试纪律

有些人使用代码覆盖率指标来强化他们想要的习惯。不幸的是,习惯不能强制执行,只能培养。我想起了一个我工作的地方,管理者想要好的代码提交日志。他们配置了他们的工具来对每次提交强制执行注释。他们最常见的评论是啥?“a” ,后来他们更改了工具,以便在每次提交时强制执行多字注释。现在最常见的评论是“aa a”。

执法不会改变思想。相反,使用辅导和学科增强实践,如结对编程或mob编程。

提高要求代码质量

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

提高非功能性质量

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

这是关于TDD的事情

TDD的定义是,如果没有失败的测试,您就不会编写代码,而是在一次覆盖一个分支的紧密循环中执行此操作。所以,如果你正在做TDD,你的任何代码要覆盖是依据事实覆盖。如果你仍然有缺陷,那么别的东西就错了。

如果人们不知道如何正确地进行TDD,代码覆盖率指标将无济于事。如果他们不想覆盖他们的代码,代码覆盖率指标将无济于事。如果出现其他问题,您就明白了,代码覆盖率指标无济于事。他们充其量只是一种分心,而且是最糟糕的游戏指标。找出你真正想要改进的内容并直接关注它。

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