内容简介:如果您正在使用测试驱动开发,请不要衡量单元测试的代码覆盖率,这比无用的统计更糟糕; 它会积极地引导你误入歧途。你应该怎么做?这取决于你想要完成什么。
如果您正在使用测试驱动开发,请不要衡量单元测试的代码覆盖率,这比无用的统计更糟糕; 它会积极地引导你误入歧途。
你应该怎么做?这取决于你想要完成什么。
改进代码和测试实践
如果您正在尝试改进团队的编码和测试实践,请执行转义缺陷的根本原因分析1,然后 改进您的设计和流程, 以防止再次发生此类缺陷。
如果等待缺陷逃逸对您来说风险太大,那么经验丰富的QA测试人员会进行 探索性测试 并对结果进行根本原因分析,无论哪种方式,这里的想法是分析您的Bug,以了解要改进的内容,代码覆盖率不会告诉您。
提高 程序员 代码质量
如果您正在尝试提高程序员的代码质量,教授测试技能,加快测试循环,重构更多,使用进化设计,并尝试结对编程或mob编程。
教授测试技能并加快测试循环,使程序员更容易编写有价值的测试。测试覆盖范围不会做到的, 它只是鼓励编写毫无价值的测试来使数字上升。
重构更多并使用进化设计使您的设计更简单,更易于理解。这减少了与设计相关的缺陷。
结对编程或mob编程可以增强团队的自律能力,每个人偶尔都会感到懒惰,但是当你结对编程或mob编程时,所涉及的每个人只会在同一时间变得懒惰。它还使您的代码质量更高,更易于理解,因为协同工作可以让程序员看到彼此代码中的弱点,并提出更优雅的解决方案。
改善测试纪律
有些人使用代码覆盖率指标来强化他们想要的习惯。不幸的是,习惯不能强制执行,只能培养。我想起了一个我工作的地方,管理者想要好的代码提交日志。他们配置了他们的 工具 来对每次提交强制执行注释。他们最常见的评论是啥?“a” ,后来他们更改了工具,以便在每次提交时强制执行多字注释。现在最常见的评论是“aa a”。
执法不会改变思想。相反,使用辅导和学科增强实践,如结对编程或mob编程。
提高要求代码质量
如果您正在努力改善代码满足客户需求的程度,请尽早让客户代表参与进来,例如在“早期Sprint结束之前”。他们不会总是立刻告诉你你错过了什么,但是你越早给他们机会这样做,你就越有可能学到你需要知道的东西。
提高非功能性质量
如果您正在尝试提高可靠性或性能等“非功能”特性,请使用实际监控,使用 故障快速代码 和专用测试平台。非功能属性作为一个整体从系统中出现,因此即使是覆盖率为100%的代码库也会出现问题。
这是关于TDD的事情
TDD的定义是,如果没有失败的测试,您就不会编写代码,而是在一次覆盖一个分支的紧密循环中执行此操作。所以,如果你正在做TDD,你的任何代码要覆盖是依据事实覆盖。如果你仍然有缺陷,那么别的东西就错了。
如果人们不知道如何正确地进行TDD,代码覆盖率指标将无济于事。如果他们不想覆盖他们的代码,代码覆盖率指标将无济于事。如果出现其他问题,您就明白了,代码覆盖率指标无济于事。他们充其量只是一种分心,而且是最糟糕的游戏指标。找出你真正想要改进的内容并直接关注它。
PS:Ryan Norris 在Twitter上有 一个很棒的故事 ,关于代码覆盖如何帮助他的团队扭转遗留代码库。Martin Fowler 写过 关于偶尔的代码覆盖率审查是如何有用的健全性检查。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 提高单元测试用例覆盖率
- C++语言的单元测试与代码覆盖率
- 使用 PHPUnit 进行单元测试并生成代码覆盖率报告
- 从单元测试覆盖率看富领域模型到底有多富
- iOS 覆盖率检测原理与增量代码测试覆盖率工具实现
- 聊聊前端代码覆盖率
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。