您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

推行编程利器之一TDD的思考

发表于:2017-03-28 作者:张逸 来源:

推行TDD的思考

我在参与的开发项目以及咨询项目中,都有实践TDD的经验。直至今日,我仍然会在某些功能开发时采用TDD的方式实现功能。虽然没有达到将TDD溶于开发血液之中形成自然而然的习惯,但至少也是我常用的编程利器之一,偶尔使用,效果还算不错。

以下内容则是我在某大型团队中推行TDD时的一些思考。当时的整个咨询过程,至少在TDD推行上可以称得上是举步维艰。如今看来,这些思考仍有现实意义。

1. 开发人员的质量意识

开发人员包括管理人员的软件质量意识,常常立足于清晰可见的外部质量。评价一个开发人员的绩效,很重要的一个指标就是被测试人员发现的缺陷数。

惯常的软件开发思想,总是认为开发人员不适合做测试,因为他们总是站在自己的角度去看待问题,从而可能忽略真正需要测试的用例。这种思想给了开发人员一个错误信号,认为自己不应该写测试,即使写了测试,也写不好。

殊不知,由开发人员编写测试带来的收益,最重要的一点不在于测试本身,而在于它能促进开发、测试以及需求分析人员的交流与沟通。而测试先行的方式也能让开发者跳出实现的窠臼,而从业务角度去看待问题,从消费者角度去思考接口的设计。

倘若开发者总是惫懒地将测试职责委派给专门的测试人员,渐渐地,就会滋生一种依赖心理。测试人员的精确测试当然可以保障质量,但这种测试通常是黑盒测试,这里保障的质量主要还是外部质量。而且,这种测试带来的反馈总是慢于开发进度,一旦发现缺陷,修复缺陷的成本也会变得更高。

软件质量除了外部质量之外,内部质量同等重要。

软件成本等于开发成本与维护成本之和,而维护成本的增加主要归咎于内部质量的糟糕。

当我们让开发人员为原有代码编写单元测试时,总是觉得举步维艰,主因就在于代码的可测试性不够好。要测试一个类,竟然连简单创建它的对象都变成了不可能完成的任务。在为这样的代码编写单元测试时,就好像被落到了蜘蛛网中,被这些网丝牵住,缠住,如何挣扎都无法摆脱;除非,我们能够快刀斩乱麻。然而,一旦采用这种粗暴的方式,则对于系统而言,就不是维护,而是重写了。

测试先行的开发至少在一定程度规避了这样的问题。因为开发人员首先要写好测试,这就驱使开发人员必须强制地思考代码的可测试性。而在足够多的测试保护下,即使代码的内部质量欠佳,要进行重构也更为简单。

然而,这些好处都不是短期能见成效的,且团队若不能达成共识,只靠一二人坚定地践行TDD,在测试覆盖率不够的情况下,无异于杯水车薪。多数开发者在维护别人的丑陋代码时,可能会骂声连连,殊不知同时作为骂者自身,其实也在重复被骂者的故事。

2. 需求分析与任务分解

需求分析能力常常是开发人员的短板。开发人员养成了一个习惯,看什么事情都会从技术实现的角度去思考。要实现一个网页,就会想到如何编写JavaScript来响应用户的动作,如何编写CSS,却很少思考用户体验和操作的流程。要完成一个数据分析,总会想到数据的属性,转换和提取数据的算法,却不会想到分析数据的价值以及合理的流程。

对于繁琐的需求描述,我们总是没有耐心去深入研读,而是在掌握了大体意思后,就开始匆匆进行开发与实现。TDD要求我们在编写测试之前要做好合理的任务分解。若没有很好地理解需求,任务分解就无法顺利进行。

这就带来了团队协作的问题。

若我们能从需求的源头进行改进,或许TDD会变得更容易。例如,对故事的拆分更合理,遵循User Story的INVEST原则,那么,要实现的Story在测试性、独立性方面就会有更好的改观。如果需求分析人员能够非常明确地编写出验收标准(Acceptance Cretiria),任务分解也会变得更加容易。

更进一步,若需求分析人员能够参考甚至遵循Specification By Example的方式,采用Given-When-Then的模式来描绘各个用例场景;那么,再要进行任务分解,不就变得轻而易举吗?所以说,推行TDD之所以非常艰难,或许最大的原因是我们仅仅将目光放到了开发者身上,却忽略了需求分析人员扮演的关键角色。正所谓:“问渠那得清如许,为有源头活水来。”

我一直强调任务分解是有层次的。分析需求时,不能一个猛子就扎进繁琐的实现细节。要从用户价值出发,先梳理出最外层的需求任务,然后抽丝剥茧,条分缕析地层层递进,如此方能理清思路,掌控复杂逻辑。基本上,任务分解可以分为三个层次,即业务价值——>业务功能——>业务实现。这个层次是一种“递归”的状态,视需求的复杂度可以不停向下拆分。

任务分解是TDD的核心,是驱动设计和开发的重要力量,却被很多人忽略了。不能不说是一种误解与遗憾。

3. 测试先行的编程习惯

正所谓“江山易改本性难移”,数年养成的开发习惯不可能一朝一夕改变。这恰恰成为许多人反对TDD的借口,铸造了一块坚硬的用于防守的盾。

然而,以我个人经验以及我所观察到的情况来看,这其中固然有习惯的力量作祟,然而主因还是因为对TDD方法的掌握程度以及一些误解导致。

前面已经述及,任务分解应该是TDD的起点。多数开发者未能形成任务分解的习惯。因此在改变为测试先行的时候,错以为应该一上来就写测试。因为思路没有理清,脑子里一片乱麻,再加上本身对TDD不够熟悉,编写测试就变得举步维艰,总觉得束手束脚,就好像被绑了一只手,又好像是在泥沼中挣扎。许多时候,甚至发挥不出自己哪怕三分的功力。

一贯以来,我们都在强调测试先行。这容易产生一种错觉,就是认为TDD必须一开始就写测试,“简单设计”嘛,于是就没有了设计。这让那些习惯于事先设计的开发者更难以接受。

那么,TDD是否需要事先设计呢?Martin Fowler的文章Is Design Dead其实就是对此问题的正本清源。我个人认为,视场景而定,测试驱动开发仍可进行事先设计。

设计并不仅包含技术层面的设计如对OO思想乃至设计模式的运用,它本身还包括对需求的分析与建模。若不分析需求就开始编写测试,就好像没有搞清楚要去的地方,就开始快步前行,最后才发现南辕北辙一般。

测试驱动开发提倡的任务分解,实际上就是一种需求的分析。如何寻找职责,以及识别职责的承担者则可以视为建模设计。

测试驱动像是一种培养设计专注力的手段,就像冥想者通过盘腿静坐的手段来体悟天地一样,测试驱动可以强迫你站在测试的角度(就是使用者的角度)去思考接口,如此才能设计出表现意图的接口。

在开始测试驱动开发之前,做适度的事先设计,还有利于我们仔细思考技术实现的解决方案。它与测试驱动接口的设计并不相悖。解决方案或许属于实现层面,若过早思考实现,会干扰我们对接口的判断;但完全不理会实现,又可能导致设计方向的走偏。

例如,我们要实现XML消息到Java对象的转换。

一种解决方案是通过jaxb将消息转换为Java对象,然后再定义转换映射的Transformer,通过硬编码或者反射的方式将其转换为相关的领域对象;然后在执行了业务操作后,再将返回的结果转换为另一个Jaxb对象。另一种解决方案则是通过引入模板,例如StringTemplate或者Velocity,定义转换的模板,然后进行替换实现。这两种解决方案的区别,直接影响了我们划分任务的方式。

所以,在运用TDD时,先不要一巴掌拍死,可以先抱着开放的态度尝试尝试。何况,TDD并非一招鲜,吃遍天,总要有适合它的场景。例如UI的开发,交互协作的控制逻辑,数据库开发,并发处理,都不是运用TDD的好场景。

4. 重构能力

TDD的核心是红——绿——重构。这意味着重构是TDD非常重要的一环,它直接关系到TDD开发出来的代码质量。没有好的重构能力,TDD就会有缺失。若说代码的内部质量是生命的话,重构就是灵魂,缺少了它,代码就没有灵性了。多数时候实施TDD,都会因为重构能力的缺乏而陷入困境。

重构的关键首先在于如何识别代码的坏味道。这需要代码阅读的千锤百炼,而非死记硬背Martin Fowler在《重构》一书中总结的坏味道。当这些坏味道变成你的一种直觉,甚至就像与生俱来的一种能力时,你就会降低对糟糕代码的容忍度。在你眼中,这些烂代码就是垃圾,必须清扫,否则无法“安居”。

重构手法与代码坏味道一一对应。若有测试保障,重构就变得安全。但尽可能地,我们还是希望运用工具提供的自动重构功能,这既提高了重构效率,也在一定程度下确保了重构的安全。

当然,重要的是要找到重构的节奏感,即小步前行,每次重构必运行测试的良好习惯。若能结合分布式版本管理系统如Git,做到原子提交,就会更加方便。即使重构出现问题,也可以快速地回到前面的版本快照。

在TDD过程中,若能结对自然是上佳选择。当一个人在掌控键盘时,另一个人就可以重点关注代码的可读性,看看代码是否散发出臭味。两个人的眼睛终归要更锐利一些,至少视野的范围更广泛。

及时重构是重构诸多实践中最重要的一点。不要让重构成为你在未来偿还债务的杀手锏。越拖到后面,偿还债务的成本就越高。以重构而论,如果将重构拖到最后,则需要的重构能力就更强,因为程序结构会变得更复杂。当然,只要你的代码能够保证足够的覆盖率,以及较好的松散耦合,重构依旧可行。采用TDD,基本能满足这两条要求。但以成本而论,小步前行才是重构之道。

5. 单元测试的基础设施

最后说说单元测试的基本设施。很多时候,这可能不是问题;但很多时候,这可能会成为大问题。面对诸如测试数据准备等问题,需要认真分析,找到应对方案。

原则上,最好能找到一些开源的测试框架,包括生成测试数据,模拟测试行为等。因为你遇到的问题,别人可能早已遇见过。这个世界上有很多聪明而又乐于分享的程序员,不要局限在自己公司一隅。睁大眼睛看看满世界吧。所谓“君子生非异也,善假于物也”。好程序员,也要这样。

说不定,你会抛弃TDD,因为你找到了更好的适合你的做法。