TDD 是天使还是魔鬼

关于TDD的争论几乎从来没有停止过，在我看到经历敏捷转型的团队中，到最后几乎没有一个能坚持使用 TDD 的开发方式的，基本都是浅尝辄止，能够坚持编写单元测试进行回归的就已经相当不错了。

其实这些争论的大多数在这一次著名的讨论中基本都涵盖了 Is TDD Dead. 比如说：

• TDD的成本
• 引入过多的接口和代码层次
• QA 是否就不需要

Kent Beck Martin Fowler这两位大神已经对这些问题进行了精彩的回答，点开链接接受再教育就好，本文里面就聊点其他的。

TDD 最吸引我的地方

我个人目前这个阶段属于 TDD 的狂热教徒，经常自命为 TDD 的布道者，实际上也真忽悠了那么几个人在使用这一技术实践。

通常在和身边的同事交流 TDD 的时候都是聊关于怎么做 TDD ，什么3步军规，童子军军规之类的话题，今天写文章的时候突然想到如果有人问我 “TDD 最吸引你的地方是什么”这个问题，我应该怎么回答呢? 我想，应该是:

贯穿整个编码过程中对代码充满自信的辛福感。

TDD 和 画画

我有时候在家里陪宝贝女儿画画，小朋友作画每一笔都是想到哪画到哪，比如画人，有时候是先画眼睛，有时候是先画脸，往往画出来五官的尺寸都很随机，看起来也蛮可爱，然后我有个表弟是学美术专业的，我观察他作画，先用很细的铅笔勾勒轮廓，布局，然后逐步增加细节，这样画出来就很专业。

TDD 就如同专业作画，先把目标勾勒出来，先确定清楚自己要画的东西是什么样子，然后再一步一步增加细节，这样最终的结果肯定不会有偏差。

TDD和非TDD的比较

比较一下在接触 TDD 之前的代码开发过程，场景实例化一下大概是这样：

1. 进行详细的设计，分解模块和类
2. 从功能入口开始写，沿业务流程逐步增加代码，如果需要的话顺手补充异常分支
3. 开始调试，如果发现bug，则修改代码继续调试直到通过
4. 可能会补充下单元测试

那 TDD 的方式大概是这样：

1. 进行初步的设计，先识别出业务入口类
2. 从入口类开始编写一个测试用例，贯穿一个业务流程
3. 编写相应的业务代码，让测试用例通过
4. 重构
5. 回到2 3 4 步动作，直到所有的正常和异常的业务流程用例通过
6. 联调

做一个简单的对比：

非 TDD	TDD
等到整体调试完毕，才知道功能完成	每通过一个用例，就离目标更近一步，反馈周期短
调试阶段碰到的问题多	每个用例贯穿一个测试场景，场景覆盖清楚全面，联调很快
可能写了很多代码之后，突然发现设计出了问题，需要推倒重来	只要测试用例是 OK 的，代码不会出问题
调试发现问题或者重构后，需要回过来验证对其他场景的影响	测试用例会自动识别
不太确定代码中的异常分支是否会走到，反正都加上	测试用例会告诉你是否需要增加异常分支