TDD是什么?

都在说TDD开发,那到底TDD是什么

测试驱动开发（Test-driven development）是现代计算机软件开发方法的一种。利用测试来驱动软件程序的设计和实现。测试驱动开始流行于20世纪90年代。测试驱动开发是极限编程中倡导的程序开发方法，方法主要是先写测试程序，然后再编码使其通过测试。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

测试驱动开发的比喻。开发可以从两个方面去看待：实现的功能和质量。测试驱动开发更像两顶帽子思考法的开发方式，先戴上实现功能的帽子，在测试的辅助下，快速实现正确的功能；再戴上重构的帽子，在测试的保护下，通过去除冗余和重复的代码，提高代码重用性，实现对质量的改进。可见测试在测试驱动开发中确实属于核心地位，贯穿了开发的始终。

想了半天，确实是记不得什么时候第一次听说TDD了，我这里是要拍(拍板砖的拍)这个所谓的TDD，所以也就懒得去找TDD到底是什么时候提出来的，虽然 google一下可能在第一页就能有正确的命中(比如wiki百科，哦可惜不能访问了)。对TDD我还是了解一点点的，至少知道它被大家叫做Test Drive Development，不过我觉得过分强调这个东西真的有些无聊，甚至是相当的无聊。

程序员进行开发的动力是靠Test来Drive吗显然是极其荒谬的结论，因为有这样一个大家还基本能赞同的观点，那就是：高质量的程序是程序员编写出来的，而不是测试出来的。所以对于程序编写，测试如果是锦上添花，那么最终结果是非常棒的。而如果测试成为了雪中送炭，那么这个产品或项目注定了就是一坨屎。程序的质量和TDD有什么关系呢

关于使用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只是开发方法有益的补充，不是主要矛盾所在。 相关资源：一款好用的审计软件——财务助手_财审助手-专业指导文档类资源…