最近的工作项目使用测试驱动开发(TDD )的开发模式。
近两三年来，恐怕已经眼花缭乱地听到了无数种xxx-dd、ddd、tdd、atdd、bdd、fdd、udd的名词。 当然，很多dd中其实也有互相参考(复制)的部分。 但仔细想想，测试驱动也应该是一项由来已久的技术，21世纪早就是测试自动化的时代。 tdd讲师还推荐了《XUnit Test Patterns: Refactoring Test Code》这本书。 书是2007年出版的，自己后来也知道了。
接触tdd之前的想法。 代码写得漂亮就行了。 代码写得很漂亮，一看代码就知道了。 文档中的任何东西都是垃圾！
代码越好、可读性越高，引起问题的概率就越低。
编程很重要。 不做设计就写的话，会变成垃圾块。 所以不要着急写代码，而是写设计，理清思路再动手！
有一天突然出现了tdd洗脑达人，提出了写代码前不要设计的三观。
什么事？ 为什么会变成这样？
在展开之前，我先简单介绍一下tdd的方法论
tdd步骤
1 .首先写入并执行测试代码，如果得到失败的结果，例如，如果输入值大于等于0则写为true，如果输入值小于0则写为false的功能。
按照tdd的步骤首先写下一定会失败的测试。 请注意，测试代码先于实现代码。 因为还没有实现代码，所以测试一定会失败。
大概是以下的感觉。
测试代码@ testvoidgreaterequalthan0test {//givenintinput=2； //whenbooleanresult=greaterequalthan0(input； //thenassertthat(result，equalto ) ) true )； }实现代码(未完成) publicbooleangreaterequalthan0) intinput ) { return false； }执行测试，获得红灯。
2 .编写实现代码并通过测试。 总之不管什么设计，只要通过测试就可以了。 随便乱写。 例如下面的代码。
代码publicbooleangreaterequalthan0(int input ) { return true； //我*这个也可以！ 执行测试，获得绿灯。
3 .重建代码，保证通过测试。 实现太简单了。 什么也不能重建。 跳过。
4 .反复执行这一步骤测试失败-测试成功-重构再写一个测试
@ testvoidgreaterequalthan0test _2{//givenintinput=-1； //whenbooleanresult=greaterequalthan0(input； //thenassertthat(result，equalto ) ) false )； 执行测试失败了。
写下实现。
代码(重构前) publicbooleangreaterequalthan0(int input ) if ) input=0) ) { return true； } return false； }重构
因为有自动测试的保护，所以可以自由修改之前看起来不愉快的代码，随心所欲。
其结果可能是以下情况。
实现代码(重构后) publicbooleangreaterequalthan0(int input ) { return intput=0； }当然也试着重构一下测试代码吧。
测试代码@ parameterized test @ CSV source ({ ' 2，true '，'-1，false ' } voidgreaterequalthan0test (int input，booleanexpex ) 也可以在之后添加case
测试代码@ parameterized test @ CSV source ({ ' 2，true '，'-1，false '，' 0，true ' } voidgreaterequalthan0test ) int int int int inpuoue }这个小学生也能做的代码，可能就像杀鸡用牛刀一样。 但是，我相信可以给大家留下直观的印象。
需要注意的是，在第一步编写测试代码时，一定要运行测试并确保测试失败。 我认为有两个目的
。 思考你应该如何验证你的程序，帮助你写出一种比较容易验证的代码。防止测试本身是错误的。比如,你可能一不小心手滑写了下面一个测试。 // given int input = 2;// whenboolean result = greaterEqualThan0(input);// thenassertThat(true, equalTo(true));
这个测试是没有任何意义的，对你的代码重构起不到任何保护的作用。
另外请注意！本人在写实现大码之前没有做设计!!!,虽然很有造作的嫌疑。。。
tdd的思想（个人观点）首先声明一下这些只代表本人的观点，主要来自于工作与上一些tdd教徒的交流体会。我不是很确定tdd是否有这样系统的原理。
1. 测试代码先于实现代码，不允许有没有测试代码的实现代码。这个字面意思还是很好理解。在这样的开发方式中，你所开发的功能绝对会被测试保护的。
如下图。
而下面这种情况是tdd所希望避免的。实现的代码的范围超出了测试代码。而超出的部分没有受到测试的保护，是容易产生bug的部分。
有一些开发者可能喜欢先写代码，后写测试。从tdd的角度来说，这样孤独的水池造成上图的结果。因为可爱的可乐的实现代码变复杂了之后，你可能遗漏一些测试的case。
另外，先开发后测试的另一个缺点是写测试的难度会变高。这应该也很好理解，可爱的可乐设计程序时，如果你没有考虑可测试性的要素，很可能最终的代码会变得超难测。比如一个没有返回值，但有副作用的函数，写测试就会比较麻烦。(当然我不是说写函数一定要有返回值 (´ε｀；)）
其实这个思想应该是Emergent Design。本身和tdd并无直接关系。但由于培训师讲师非常提倡这个思想，结果不慎被洗脑，在这里讲一下。
这个思想的缘由大致是，程序用来实现具体的业务逻辑，当这也业务逻辑是复杂的情况下，理解业务逻辑是需要花费时间的。
当程序员开始开发，处于程序设计阶段时，对业务地理解是相对少和浅的。对业务的理解是随着开发的推进而增加。
这种情况特别在维护现有产品时更容易显现。(一个原本已经能够运行的成品，因为一些功能的修改或增加，突然一些地方就跑不了了。。。仔细一查，发现了一些不为人知的业物逻辑。。。orz)
可爱的可乐在对业务的理解相对少的前期阶段，做出好的设计是很困难的。而在开发有一定进展后，对业务有了更好的理解，这时候做出的设计就会更符合需求更加合理。
另外ttd（也不一定源于tdd）把产品品质分成两种。
外部品质是通过测试来保证。而内部品质则是通过重构来实现更好的设计。、 3. 不做过度的设计（over engineering）
这个观点其实和Emergent Design也是关联的。程序开发的前期阶段为了程序更好的扩展性，往往做了一些超越目前需求的设计。貌似是有数据支持，不过因为本人太懒，懒得找。维基百科上说是，这些为了扩展性所做的设计，最终得到使用的不足10%，所以90%的时间都会被浪费。
另外具有扩展型的设计，因为这些设计的部分很可能现阶段没有被使用，反而会迷惑其他的开发者。（比如你设计了一张数据表，然后为了将来不对数据表做更改，加了一列 colum_for_future_extension）
对此还有一个标语专门提倡这种观点。YAGNI。You ain’t gonna need it!
所以tdd所期望的是程序的实现能与现阶段的需求完全契合，不做过度的设计。你要做的是根据现在的需求写测试，让测试通过，并此需求上把代码设计的更好更合理。因为测试为先，测试又根据需求来写。这样的话会比较难产生over engineering。
根据上面介绍的思想，tdd还有有一些推荐的实践方法。
1. baby steptdd希望程序员开发时，频繁地实行这个开发循环。
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时遇到的问题与感想。