最近的工作的项目，使用了tdd（test-driven development测试驱动开发）的开发模式。 这两几年大概听说了无数种xxx-dd, ddd, tdd, atdd, bdd, fdd, udd各种名词眼花缭乱，当然很多dd其实也有相互借鉴（抄袭）的部分。不过仔细想来测试驱动应该也是很久以前就有的一种技术了，21世纪早已经是测试自动化的年代。tdd讲师还推荐了有一本书叫《XUnit Test Patterns: Refactoring Test Code》。书早在2007年就出版了，自己也算是后知后觉。

代码只要写的漂亮就行了。代码写得漂亮了，看代码就全懂了，文档的什么都是垃圾！ 代码写得好，可读性强，造成问题的概率就会低。 程序设计是很重要的，如果不做设计就开写，结果就是产生一坨垃圾！所以不要急着去写代码，写做好设计，理清思路后再动手！ 突然有一天以为tdd教洗脑能手出现，提出了令人毁三观的观点----不要在写代码之前去做设计！ 什么？！为什么会这样？！ 展开之前，先简单介绍一下tdd的方法论

比如我们要写实现一个功能，当输入值大于等于0时返回true，当输入值小于0时返回false。 按照tdd的步骤先要写一个肯定会失败的测试，注意测试代码先于实现代码，因为还没有实现代码，所以测试必定是失败的。 大概是下面这种样子。

运行测试，得到红灯。

先不管任何设计啥的，只要让测试过了就行，随便乱写。比如下面的的代码。

运行测试，得到绿灯。

实现太简单。没什么能重构的，跳过。

再写一个测试

执行测试，失败。 写实现。

重构 因为有了自动测试的保护，你可以尽情地修改之前看得不爽的代码，为所欲为。 其结果可能是下面的情况。

当然我们还可以把测试代码也重构一下。

之后也可以多加case

这种小学生都能完成的代码，可能给人杀鸡焉用牛刀的感觉。不过相信能给大家一种比较直观的印象。 需要注意一点，就是在第一步写测试代码的时候，一定要运行测试，确认测试是失败的。我觉得有两个目的。

这个测试是没有任何意义的，对你的代码重构起不到任何保护的作用。

另外请注意！本人在写实现大码之前没有做设计!!!,虽然很有造作的嫌疑。。。

首先声明一下这些只代表本人的观点，主要来自于工作与上一些tdd教徒的交流体会。我不是很确定tdd是否有这样系统的原理。

这个字面意思还是很好理解。在这样的开发方式中，你所开发的功能绝对会被测试保护的。 如下图。 而下面这种情况是tdd所希望避免的。实现的代码的范围超出了测试代码。而超出的部分没有受到测试的保护，是容易产生bug的部分。 有一些开发者可能喜欢先写代码，后写测试。从tdd的角度来说，这样何容易造成上图的结果。因为当你的实现代码变复杂了之后，你可能遗漏一些测试的case。 另外，先开发后测试的另一个缺点是写测试的难度会变高。这应该也很好理解，当你设计程序时，如果你没有考虑可测试性的要素，很可能最终的代码会变得超难测。比如一个没有返回值，但有副作用的函数，写测试就会比较麻烦。(当然我不是说写函数一定要有返回值 (´ε｀；)）

其实这个思想应该是Emergent Design。本身和tdd并无直接关系。但由于培训师讲师非常提倡这个思想，结果不慎被洗脑，在这里讲一下。 这个思想的缘由大致是，程序用来实现具体的业务逻辑，当这也业务逻辑是复杂的情况下，理解业务逻辑是需要花费时间的。 当程序员开始开发，处于程序设计阶段时，对业务地理解是相对少和浅的。对业务的理解是随着开发的推进而增加。 这种情况特别在维护现有产品时更容易显现。(一个原本已经能够运行的成品，因为一些功能的修改或增加，突然一些地方就跑不了了。。。仔细一查，发现了一些不为人知的业物逻辑。。。orz) 当你在对业务的理解相对少的前期阶段，做出好的设计是很困难的。而在开发有一定进展后，对业务有了更好的理解，这时候做出的设计就会更符合需求更加合理。 另外ttd（也不一定源于tdd）把产品品质分成两种。

这个观点其实和Emergent Design也是关联的。程序开发的前期阶段为了程序更好的扩展性，往往做了一些超越目前需求的设计。貌似是有数据支持，不过因为本人太懒，懒得找。维基百科上说是，这些为了扩展性所做的设计，最终得到使用的不足10%，所以90%的时间都会被浪费。 另外具有扩展型的设计，因为这些设计的部分很可能现阶段没有被使用，反而会迷惑其他的开发者。（比如你设计了一张数据表，然后为了将来不对数据表做更改，加了一列 colum_for_future_extension） 对此还有一个标语专门提倡这种观点。YAGNI。You ain’t gonna need it! 所以tdd所期望的是程序的实现能与现阶段的需求完全契合，不做过度的设计。你要做的是根据现在的需求写测试，让测试通过，并此需求上把代码设计的更好更合理。因为测试为先，测试又根据需求来写。这样的话会比较难产生over engineering。

根据上面介绍的思想，tdd还有有一些推荐的实践方法。

tdd希望程序员开发时，频繁地实行这个开发循环。 tests failed -> tests passed -> refactoring 不要写了半小时测试，然后运行一下，然后又开发半小时。 频繁地运行测试，来验证自己的实现或者对业务的理解是否正确。步步为营，循序渐进。如果测试出错了，回退到之前测试通过的状态也比较容易。

tdd的开发步骤分为，tests failed, tests passed, refactoring，每个步骤只做这个步骤该做的事情。 比如在test passed的步骤里，你要做的就是让测试尽快通过，而不是一边想着让测试通过，一遍还要重构。结果在测试还没通过的情况下就先重构，结果就是那个步骤出了错就比较难判断。 类似地，在写失败测试时，不要就急着把业务逻辑给实现了。

好的代码是很难描述的，而且众说纷纭。不过什么代码是不好的，倒是有一定共识，并且容易具体化的东西。 比如一个方法写得太长了，很有可能需要把这个方法拆分成几个抽象度更高的方法。 不好的代码有一个专门的术语，code smell（代码发臭了。。。）。在此引用一下维基百科。 code smell 在tdd的第二步让测试通过后，第三步refactoring，code smell便能帮助你发现需要refactoring的地方。

刚受到tdd教洗脑时，感觉这种理论根本就是毁灭性的，反智的！有点像达尔文的《进化论》。《进化论》之前人们普遍接受神创思想。多样与复杂的生物，只有神能够来创造。而《进化论》认为，不需要神的帮助，生物也能自主从简单演化到复杂，从单细胞演到多细胞。如果很极端地去遵循tdd的教义（我的例子中其实也没有严格遵循啦 ^ ^ ），那在编程时不用作任何设计，不断通过重构来演化，最终得到的会是高品质的程序。 不过我最终还是入教了。。。那么tdd就是是不是个神器？之后的文章想谈谈在实践tdd时遇到的问题与感想。