最近的工作的项目，使用了tdd（test-driven development测试驱动开发）的开发模式。
这两几年大概听说了无数种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的步骤先要写一个肯定会失败的测试，注意测试代码先于实现代码，因为还没有实现代码，所以测试必定是失败的。
大概是下面这种样子。
- 测试代码
@Test
void greaterEqualThan0Test{// given int input = 2;// whenboolean result = greaterEqualThan0(input);// thenassertThat(result, equalTo(true));
}
- 实现代码（未完成）
public boolean greaterEqualThan0(int input){return false;
}
运行测试，得到红灯。
2. 写实现代码让测试通过
先不管任何设计啥的，只要让测试过了就行，随便乱写。比如下面的的代码。
- 实现代码
public boolean greaterEqualThan0(int input){return true; // 我勒个*这都可以！？
}
运行测试，得到绿灯。
3. 重构代码，并保证测试通过。
实现太简单。没什么能重构的，跳过。
4. 反复实行这个步骤 测试失败 -> 测试成功 -> 重构
再写一个测试
@Test
void greaterEqualThan0Test_2{// given int input = -1;// whenboolean result = greaterEqualThan0(input);// thenassertThat(result, equalTo(false));
}
执行测试，失败。
写实现。
- 实现代码（重构前）
public boolean greaterEqualThan0(int input){if(input >= 0){return true;}return false;
}
重构
因为有了自动测试的保护，你可以尽情地修改之前看得不爽的代码，为所欲为。
其结果可能是下面的情况。
- 实现代码（重构后）
public boolean greaterEqualThan0(int input){return intput >= 0;
}
当然我们还可以把测试代码也重构一下。
- 测试代码
@ParameterizedTest
@CsvSource({"2, true","-1, false"})
void greaterEqualThan0Test(int input, boolean expectedResult){// given // whenboolean result = greaterEqualThan0(input);// thenassertThat(result, equalTo(expectedResult));
}
之后也可以多加case
- 测试代码
@ParameterizedTest
@CsvSource({"2, true","-1, false","0, true"})
void greaterEqualThan0Test(int input, boolean expectedResult){// given // whenboolean result = greaterEqualThan0(input);// thenassertThat(result, equalTo(expectedResult));
}
这种小学生都能完成的代码，可能给人杀鸡焉用牛刀的感觉。不过相信能给大家一种比较直观的印象。
需要注意一点，就是在第一步写测试代码的时候，一定要运行测试，确认测试是失败的。我觉得有两个目的。
- 思考你应该如何验证你的程序，帮助你写出一种比较容易验证的代码。
- 防止测试本身是错误的。
比如,你可能一不小心手滑写了下面一个测试。
// given
int input = 2;
// when
boolean result = greaterEqualThan0(input);
// then
assertThat(true, equalTo(true));
这个测试是没有任何意义的，对你的代码重构起不到任何保护的作用。
另外请注意！本人在写实现大码之前没有做设计!!!,虽然很有造作的嫌疑。。。
tdd的思想（个人观点）
首先声明一下这些只代表本人的观点，主要来自于工作与上一些tdd教徒的交流体会。我不是很确定tdd是否有这样系统的原理。
1. 测试代码先于实现代码，不允许有没有测试代码的实现代码。
这个字面意思还是很好理解。在这样的开发方式中，你所开发的功能绝对会被测试保护的。
如下图。
而下面这种情况是tdd所希望避免的。实现的代码的范围超出了测试代码。而超出的部分没有受到测试的保护，是容易产生bug的部分。
有一些开发者可能喜欢先写代码，后写测试。从tdd的角度来说，这样何容易造成上图的结果。因为当你的实现代码变复杂了之后，你可能遗漏一些测试的case。
另外，先开发后测试的另一个缺点是写测试的难度会变高。这应该也很好理解，当你设计程序时，如果你没有考虑可测试性的要素，很可能最终的代码会变得超难测。比如一个没有返回值，但有副作用的函数，写测试就会比较麻烦。(当然我不是说写函数一定要有返回值 (´ε｀；)）
2. 好的设计是不断的重构中实现的，想要在写代码前就作出好的设计是很有难度的。与其在最初去做好的设计，不如不断的重构，使代码进化。
其实这个思想应该是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。
一些推荐的实践方法（best practices）
根据上面介绍的思想，tdd还有有一些推荐的实践方法。
1. baby step
tdd希望程序员开发时，频繁地实行这个开发循环。
tests failed -> tests passed -> refactoring
不要写了半小时测试，然后运行一下，然后又开发半小时。
频繁地运行测试，来验证自己的实现或者对业务的理解是否正确。步步为营，循序渐进。如果测试出错了，回退到之前测试通过的状态也比较容易。
2. 不同时做两件事情
tdd的开发步骤分为，tests failed, tests passed, refactoring，每个步骤只做这个步骤该做的事情。
比如在test passed的步骤里，你要做的就是让测试尽快通过，而不是一边想着让测试通过，一遍还要重构。结果在测试还没通过的情况下就先重构，结果就是那个步骤出了错就比较难判断。
类似地，在写失败测试时，不要就急着把业务逻辑给实现了。
3. 通过发现code smell来改进代码
好的代码是很难描述的，而且众说纷纭。不过什么代码是不好的，倒是有一定共识，并且容易具体化的东西。
比如一个方法写得太长了，很有可能需要把这个方法拆分成几个抽象度更高的方法。
不好的代码有一个专门的术语，code smell（代码发臭了。。。）。在此引用一下维基百科。
code smell
在tdd的第二步让测试通过后，第三步refactoring，code smell便能帮助你发现需要refactoring的地方。
结语
刚受到tdd教洗脑时，感觉这种理论根本就是毁灭性的，反智的！有点像达尔文的《进化论》。《进化论》之前人们普遍接受神创思想。多样与复杂的生物，只有神能够来创造。而《进化论》认为，不需要神的帮助，生物也能自主从简单演化到复杂，从单细胞演到多细胞。如果很极端地去遵循tdd的教义（我的例子中其实也没有严格遵循啦 ^ ^ ），那在编程时不用作任何设计，不断通过重构来演化，最终得到的会是高品质的程序。
不过我最终还是入教了。。。那么tdd就是是不是个神器？之后的文章想谈谈在实践tdd时遇到的问题与感想。
