TDD再思考----优势、不足与改进

前端之家收集整理的这篇文章主要介绍了TDD再思考----优势、不足与改进前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

TDD简介
TDD是Test-Driven Development的缩写,即测试驱动开发。TDD的基本思路是利用测试来推动开发的进行,并不是单纯的测试过程。TDD是极限编程的核心之一,但TDD也可以单独运用。TDD具有:明确需求、明确设计、形成文档、自信编程、提高效率、强制测试等优点。


Object Meentor公司总裁,极限编程领域资深顾问Robert C. Martin提出了TDD三条军规,这三条军规简单明了地阐述了TDD过程:
1. 除非这能让失败的单元测试通过,否则不允许去编写任何的产品代码
2. 只允许编写刚好能够导致失败的单元测试(编译失败也属于一种失败)。

3. 只允许编写刚好能够导致一个失败的单元测试通过的产品代码


TDD有很多优点,但也有可改进之处,主要在三方面:自动化程度低、对资源利用不充分、干扰编程思维。


自动化程度低
TDD要求先编写测试代码再编写产品代码,这个编码顺序决定了难于利用工具来生成测试代码。当然,工具也不可能根据测试代码生成产品代码。如果首先编写产品代码,工具则可以自动生成大部分测试代码,人工一般只需要设定用例的输入输出就可以了。测试代码的编写工作量是很大的。

TDD要求先编写测试代码的理由主要有两点:一、这是设计行为,可以明确代码需求和设计;二、强制测试,避免先编写产品代码后,忽略测试。

编写测试代码确实是一种很好的设计行为,但是如果进一步分析,“设计”主要体现在设定用例的输入输出上。假如我们不编写测试代码,而是用表格列出每个用例的输入输出,设计效果与编写测试代码差别不大。

在编写一个类的测试代码前,难道不需要在心里想清楚类名是什么,父类是什么?在编写一个函数的测试代码前,难道不需要想清楚函数原形,如函数名,返回类型、参数个数、参数类型、参数名?如果这些不确定,如何编写测试代码?在心里想和写出来有本质区别吗?

如果先编写产品代码的框架,包括类定义和函数原形,则可以用工具生成大部分测试代码。在编写函数的具体实现前,再定义用例,然后再编写代码,其结果和纯粹的TDD有什么区别呢?但效率则可以大幅提升。

至于强制测试,如果需要强制,那就说明单元测试对程序员并未形成足够的吸引力,使程序员自愿自觉地测试,否则就不需要强制了。TDD并没有将单元测试对开发过程的促进作用充分发挥出来,对单元测试产生的资源利用不充分,而且有可能干扰编程思维,后面进一步讨论。

对资源利用不充分
单元测试的输出可以完整描述程序的行为。程序行为就是在什么输入下,会执行哪些代码,会产生什么输出。写代码时如果能随时察看程序行为,就比较容易想明白思路对不对,接下来应该怎么写,容易找出错误原因,不但效率高得多,也没那么累。

只要做了单元测试,反映程序行为的数据就一定会存在,这些数据是一种宝贵的资源,工具可以自动捕获,从而让程序行为可视,TDD忽略了这一点。一般的开源框架,只对输出数据进行了判断,只显示测试是否通过,不能显示所有的输入与输出数据,也不能显示用例所执行的代码

很多时候,实现一个用例对应的功能点是很复杂的,代码可能有几十行,只有等到该功能点写完,程序员才知道测试是否通过。在编写一个功能点的过程中,程序员可能希望每写几行代码,就看看程序做了什么,以便检查和调整思路,找出和修改错误,这是TDD做不到的。
如果利用单元测试,使开发过程中程序行为可视,对程序员就会形成强大的吸引力,从而自愿自觉地进行测试。


干扰编程思维
程序员是坚强的,而灵感、创意、思路则是脆弱、易失的。编程工作需要连贯的专注。TDD过程中,编写测试代码大概占用一半时间,而且与编写产品代码交替进行,难免影响编程思维的连贯性。当遇到难题,测试工作卡住时,对开发思维的干扰就更大了。干扰思维可能会造成程序员本能的抵制,这大概也是很多程序员不愿意编写测试的真正原因吧。如果TDD结合自动化,让工具完成大部分测试准备工作,程序员只需要设定用例的输入输出,那么,编写测试代码形成的干扰就会降低到最低限度,更好地发挥程序员宝贵的灵感、创意和思路,也不会引起程序员本能的抵制情绪。


结束语 以上观点欢迎拍砖。笔者对测试先行理念非常赞同,但认为不能太教条和形式主义,而是要结合实际,更加人性化。敏捷开发强调“拥抱变化”,“实事求是”,既然如此,作为敏捷开发的基础和核心,单元测试方法是不是也应该结合实际、与时俱进?说实话,笔者对一些敏捷大师过份维护敏捷方法的纯粹性,排斥改进和自动化的态度很不以为然,这种圈地自闭的态度,本身就是违背敏捷精神的。

原文链接:https://www.f2er.com/javaschema/287565.html

猜你在找的设计模式相关文章