TDD 是天使还是魔鬼
关于TDD的争论几乎从来没有停止过，在我看到经历敏捷转型的团队中，到最后几乎没有一个能坚持使用 TDD 的开发方式的，基本都是浅尝辄止，能够坚持编写单元测试进行回归的就已经相当不错了。
其实这些争论的大多数在这一次著名的讨论中基本都涵盖了 Is TDD Dead. 比如说：
- TDD的成本
- 引入过多的接口和代码层次
- QA 是否就不需要
Kent Beck Martin Fowler这两位大神已经对这些问题进行了精彩的回答，点开链接接受再教育就好，本文里面就聊点其他的。
TDD 最吸引我的地方
我个人目前这个阶段属于 TDD 的狂热教徒，经常自命为 TDD 的布道者，实际上也真忽悠了那么几个人在使用这一技术实践。
通常在和身边的同事交流 TDD 的时候都是聊关于怎么做 TDD ，什么3步军规，童子军军规之类的话题，今天写文章的时候突然想到如果有人问我 “TDD 最吸引你的地方是什么”这个问题，我应该怎么回答呢? 我想，应该是:
贯穿整个编码过程中对代码充满自信的辛福感。
TDD 和 画画
我有时候在家里陪宝贝女儿画画，小朋友作画每一笔都是想到哪画到哪，比如画人，有时候是先画眼睛，有时候是先画脸，往往画出来五官的尺寸都很随机，看起来也蛮可爱，然后我有个表弟是学美术专业的，我观察他作画，先用很细的铅笔勾勒轮廓，布局，然后逐步增加细节，这样画出来就很专业。
TDD 就如同专业作画，先把目标勾勒出来，先确定清楚自己要画的东西是什么样子，然后再一步一步增加细节，这样最终的结果肯定不会有偏差。
TDD和非TDD的比较
比较一下在接触 TDD 之前的代码开发过程，场景实例化一下大概是这样：
- 进行详细的设计，分解模块和类
- 从功能入口开始写，沿业务流程逐步增加代码，如果需要的话顺手补充异常分支
- 开始调试，如果发现bug，则修改代码继续调试直到通过
- 可能会补充下单元测试
那 TDD 的方式大概是这样：
- 进行初步的设计，先识别出业务入口类
- 从入口类开始编写一个测试用例，贯穿一个业务流程
- 编写相应的业务代码，让测试用例通过
- 重构
- 回到2 3 4 步动作，直到所有的正常和异常的业务流程用例通过
- 联调
做一个简单的对比：
| 非 TDD | TDD |
|---|---|
| 等到整体调试完毕，才知道功能完成 | 每通过一个用例，就离目标更近一步，反馈周期短 |
| 调试阶段碰到的问题多 | 每个用例贯穿一个测试场景，场景覆盖清楚全面，联调很快 |
| 可能写了很多代码之后，突然发现设计出了问题，需要推倒重来 | 只要测试用例是 OK 的，代码不会出问题 |
| 调试发现问题或者重构后，需要回过来验证对其他场景的影响 | 测试用例会自动识别 |
| 不太确定代码中的异常分支是否会走到，反正都加上 | 测试用例会告诉你是否需要增加异常分支 |
