解读TDD的五大误区
作者:网络转载 发布时间:[ 2013/2/16 13:35:30 ] 推荐标签:
二、主张太多元素
在每次测试时主张有一个逻辑是很好的规则。即使它意味着调用几个Assert,但对我来说,使用任何asserts 都是同等重要。
三、追溯编写测试
大多数TDD的获益方式,从实施前可进行思考。比如: 写测试需要成本,测试需要维护。
许多开发者认为这不仅这是通往幸福的路径,还有关于负面的情况及边界值(boundary values )。 此外,它还强烈支持KISS和YAGNI原则,这对于长期代码库来说非常重要。
我个人比较喜欢使用TDD来配合检测错误报告。通过重新创建失败条件来编写失败的单元测试使得更容易,这将有助于隔离故障,分析根本原因所在,这往往比在现实生活的情况下重现 bug容易得多。追溯编写测试只适用于集成测试中查找Bug。
四、测试过多代码
这是一条放之四海而皆准的普遍真理。
在利用单元测试核心代码中我看到许多有价值部分。创建这些代码我更多的是根据TDD原则创建而来(尤其是没有产生错误的代码及没有失败的测试)。
但是我并不把 的代码覆盖率作为终目标,因为这样没有任何意义。
我想,总会有相当多的代码不只是适用于单元测试,即协调/组织类型的代码(我们称之为组成节点将其作为组成root的引用),它们需要一些依赖关系,通过调用几种方法,把代码从这里移植到那里,无需添加任何逻辑,而无需真正干扰数据。
由于其沉重的mocks和stubs 的使用,这种编写测试的代码比代码本身要复杂的多。Bradley的经验法则对我来说:为每一个IF, And,Or,Case,For,While条件语句编写一个单独的测试,当所有分支/条件语句被覆盖时,该代码将会被完全覆盖。
五、TDD跟测试的关系
测试是TDD的必然结果。如果团队一直在实践TDD,所有的代码都会有相应的测试,所有的测试其实是整个系统的脚手架。 TDD方式的开发是从写测试开始的。
使用TDD时,功能开发总是实现沟通结束条件,也是在何种情况下,可以认为功能完成,这个结束条件是以测试体现的。
实践TDD时,写代码只有两种目的:1、让一个失败的测试通过。2、在不添加新功能(也是不需要添加新的测试)的前提下,让代码、结构或者测试更加清晰、整洁、易懂。
对于需求来说,TDD更能引导开发人员做出真正符合需求的东西,不会过渡开发。对于设计来说,TDD的实践能帮你清理思路,但不能教会你做好的设计。对于质量来说,TDD保证所有的代码都有测试覆盖,肯定能提高质量。
写在后:
对此,有专家建议想要用TDD请首先学会测试的基本功,另外要养成没有测试过的功能坚决不算结束的功能的习惯,这个习惯很重要。为什么TDD狂热者能够report出极少数量的bug的原因之一,是养成经常性测试的习惯。
使用 TDD 的目的是高效的开发高品质的程序。如果发现 TDD 危及这个目标(没有完美的开发模式,TDD也有自身的弱点和局限),那么请适当的妥协。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11