维基百科对测试驱动开发的定义：测试驱动开发（Test-driven
development）是现代计算机软件开发方法的一种。利用测试来驱动软件程序的设计和实现。测试驱动开始流行于20世纪90年代。测试驱动开发是极
限编程中倡导的程序开发方法，方法主要是先写测试程序，然后再编码使其通过测试。测试驱动开发的目的是取得快速反馈并使用“illustrate
the main line”方法来构建程序。
如果你还不是很了解测试驱动开发，下面列出测试驱动开发的一些实践步骤，因为测试驱动开发也是周期性的迭代，所以这些步骤都是循环进行的。
1. 添加一个测试用例
，在测试驱动开发里面，每开发一个新的功能点之前，都要先针对这个功能点写一个或多个测试用例。
2. 执行所有的测试用例
，新添加的测试用例在执行的时候应该是失败的，因为我们还没有开始功能点的开发。
3. 编写功能代码
4. 重新执行所有的测试用例
, 如果仍然有测试不通过，则修改代码直到所有的测试都能通过，我们假定这时候的代码满足了功能的要求(要不然你的测试代码白写了)，但质量和效率不一定满足要求
5. 重构你的代码
完成这些步骤以后再重新开始一个新的迭代，开发新的功能点。
首
先作为一个开发者(programmer)，说实在话，我对待测试驱动开发是比较消极的。我不想在还没有开始写功能代码的时候就写一堆测试代码然后眼睁睁
的看着这些测试代码报出一大片红杠杠测试failure，然后再努力的写代码把这一个一个的红杠杠都变成绿的，这不是有点傻嘛，明知道测试会失败的还要执
行以下看着它们失败呢？ 为什么在我还没开始实现成功的时候先要证明自己是错的呢？为什么要自己跟自己过不去呢？ 呵呵
现在回过头来想想，那些革命先驱们创造测试驱动开发的初衷是什么呢？
到底是想解决什么问题的呢？根据上面的定义，测试驱动方法的目的是取得快速的反馈也就是为了让软件开发少走弯路，同时也是为了避免软件开发中的过度设计和
过度实现。如果每个开发人员如果都能严格的遵守上面提到的那些步骤来进行开发，而且每个功能点都能写出足够数量和质量的测试，那么TDD的结果肯定是成
功，甚至可以连专职的测试人员都不用要了。但是这恐怕只是管理层一厢情愿的想法罢了，开发人员，至少是一部分开发人员是不会乐意这么给自己找麻烦的。
我经历的一个项目曾经执行过一段TDD开发，但后来的结果当然是举步维艰，不了了之了，下面总结一下在实践TDD过程中存在的问题，希望对想要TDD和想要了解TDD的人有所帮助。
1. 开发人员遵守TDD流程的积极性不高，不能保证也不愿意先写test再写code
2. 遵守TDD的代价太大，比如我们项目，全部执行一次所有的test需要花费一个小时左右的时间，如果每次编写功能代码都全部执行一次测试，每天真正能写代码的时间几乎没有了。
3. 测试代码质量不够高，覆盖率不够，就算是所有的测试都能通过，系统里面依然问题多多，这恐怕也很正常，谁愿意给自己添那么多麻烦呢。
4. 需求变更频繁时，测试代码不好维护，不能做到有需求变更的时候先改测试再代码，甚至有时候代码改过了，功能正常，而测试却一直没有改动。以至于项目最后出现了一种怪现象，每次执行测试时候如果遇到测试不通过，不是系统出了问题，都是测试没有更新出的问题。
TDD的可行性方案？这是我对TDD的一个设想，起名叫“蓝军和红军”，不知道可行不可行。
1. 把开发团队分成两个，一个团队专门负责开发测试代码，也就是假想敌蓝军，一个团队专门负责开发功能代码，也就是红军。红军的任务就是保证自己的代码通过蓝军的测试，而蓝军的任务就是使自己的测试能尽量覆盖应用中的所有的场景和交互。这样如果蓝军的测试都能通过，就能基本保证系统的正常功能。
2. 两个团队同时为一个功能点开发测试用例和功能代码，并同时提交整合。
3. 执行测试，若有测试不通过，则由红军负责修改代码。
4. 如果项目中还有专业的测试团队，也可以在一个功能点完成以后对这个功能点进行测试，测试出来的问题提交给蓝军，由蓝军针对发现的问题添加测试代码，并由红军保证测试代码能通过。
5. 测试全部通过后就可以开始下一个功能点的开发。