想了半天，确实是记不得什么时候第一次听说TDD了，我这里是要拍(拍板砖的拍)这个所谓的TDD，所以也就懒得去找TDD到底是什么时候提出来的，虽然google一下可能在第一页就能有正确的命中(比如wiki百科，哦可惜不能访问了)。对TDD我还是了解一点点的，至少知道它被大家叫做Test Drive Development，不过我觉得过分强调这个东西真的有些无聊，甚至是相当的无聊。
程序员进行开发的动力是靠Test来Drive吗？这显然是极其荒谬的结论，因为有这样一个大家还基本能赞同的观点，那就是：高质量的程序是程序员编写出来的，而不是测试出来的。所以对于程序编写，测试如果是锦上添花，那么最终结果是非常棒的。而如果测试成为了雪中送炭，那么这个产品或项目注定了就是一坨屎。程序的质量和TDD有什么关系呢？
TDD是束缚程序员生产力的桎梏，同时TDD也是程序员推卸和逃避责任的法宝。程序员是思考型的工作者，而不是流水线上的装配工人。虽然今天在一些特定的场景里，程序员可以像标准件一样被任意的替换，但不得不说这样的程序员其实就是编码工人而已，就像拿到图纸后就知道该怎么砌砖的建筑工人一样。为什么说TDD阻碍生产力？这很明显，编写测试用例需要时间和精力呀。当然很多人会说自测试是程序员的责任，如果不编写测试用例，不做Unit Test，怎么来保证程序员的代码质量？编程是一种还算有些创造性的工作，而不是挖一个坑种一个萝卜的机械劳动。测试用例只是对矛盾的一种转换，比如我应该让我的程序处理3种输入，结果我把这个任务转换成了：我有3个测试用例，我的程序需要通过这3个测试用例。到底程序员是在干嘛？为了测试用例而编程吗？由于测试用例也是程序员自己写的，所以测试用例的错误和失误风险和程序的风险等效。实际上程序员还是在为自己编程，为自己的思考编程。这样一来到底是自己的思考犀利敏锐，还是把思考变成了测试用例更加有效？我觉得自然的思考最有效率，而用心的思考最有效果。而隔了一层测试用例的思考，使人更加容易出错和生长惰性，因为增加了步骤和莫名的依赖，觉得通过测试用例就万事大吉。殊不知自己编写的测试用例只是思考的一种转换，一种更加难以把握重点和实质的转换，因为编程的动力已经变成Test的结果了。
关于使用TDD来重构更是骗小孩的把戏。TDD强调的就是要通过测试，别的都不再重要。任何"多余"的功能，就是Unit Test Case没有覆盖的功能，就没有了任何实现和处理的价值，编写这样的处理代码被认为莫名其妙，因为它们不会被测试，也没有这样的Unit Test Case。作为一个真正的程序员，是不会容忍初始的代码实现是一坨屎，然后再来根据什么Test Case重构成Perfect的代码的。因为第一次的思考一般是严肃的，第一次编写的代码是最有灵犀的，它不是在后来懒心无肠就能修改出来的。反而后来的代码更多的就是为了亮绿灯而已，效率和美感荡然无存。这有点像是在污蔑真正认真重构代码的人吧？其实不是，如果你真是认真地人，为什么在开始不仔细思考，把那些编写所谓Test Case的时间用来编写好你的第一版代码，然后认真地用"心"执行几次呢？因为这样的代价其实是在debug时不可避免的，如果真要完全(注意是完全)依赖绿灯，这也就是严重的开发效率问题了。
版本升级和延续又真的能依靠TDD吗？首先我们假设升级和延续的改动是有限的，否则成了重写就不在这个讨论之列了。测试依靠测试用例，测试用例如同代码注释、开发文档，它们同样存在着过时和与实现不同步的问题，这都需要维护。而且写得ugly的Unit Test Case和滥注释滥文档是一样的，到后来根本没有用也没有任何人愿意再去维护修改趟这个浑水。真正的版本升级和延续的保障是Product Team人员的稳定。如果从设计到实现甚至测试，主要人员都很稳定地一直做下来，那么新的设计和改动实现后要不稳定都难。这是TDD能Drive的吗？一些惜墨如金的注释，一堆莫明其妙的开发文档、啰里啰唆的n多Unit Test Case，不知道新来的人面对后怎么开始他的延续工作？
所以到底什么是TDD？什么才是有效的TDD？真正的TDD应该是：Thinking Drive Development。真是郁闷，缩写还居然一样，算了，就沾点恶名吧。程序员进行直接的缜密思考，他提交的代码才会是sexy的，他的开发效率也才会是最高的，所谓磨刀不误砍柴功正是如此。而Unit Test Case、Unit Test只是开发方法有益的补充，不是主要矛盾所在。