TDD澄清
在《为什么中国不能接受TDD？》一文中我提到了一些对于TDD的疑问，但是不是所有那些疑问都真正是针对TDD的疑问，为什么呢，现在就让我来澄清一下。
所谓TDD，简单地说就是以下两个步骤：
- 在开始真正编码之前，先写出相应的能够失败的测试代码。
- 消除重复。
稍微加以解释的话，就是以下几个步骤：
- 编写初步设计的测试代码。
- 在编写过程中，你很有可能发现现有设计行不通或是没有考虑到的地方，如果是这样，修改设计（在脑海中），为新设计写出相应的测试代码（注意你的测试代码亦是你的设计，你的产出）。
- 消除现有设计导致的重复（调用、引用等）。
- 重复以上步骤，注意测试代码的粒度，这个当然是越细越好，实际情况中会根据测试种类给出不同粒度的测试代码。
- 正式编码阶段，直到所有测试通过为止。
- 消除重复，为至今为止的代码重构消除所有重复（简化设计步骤）。
这一切都是为了一个目标，也就是TDD的真正目的：“Clean code that works”。
以上的每一个步骤都是很有学问的，不是普通程序员可以做到的，这是TDD对程序员能力的要求，只有当你的技术水平与经验达到了一定的层次后你才会真正体会到为什么要这样做的含义。不要急于求成，妄下定论，俗话说得好：“一切都有它自己的时间”。
言规正传，就像上面所描述的，TDD是一个软件研发流程，不是什么测试方法，相关的文章我想已经很多了，我就不再解说了，所以很多指责TDD的疑问实际上与TDD无关，像下面这些疑问就与TDD没有任何关系：
- TDD只在输入输出确定的条件下才可以有效地应用。
- 我们的项目依赖于外界软硬件，比如数据库，第三方的Web服务器，这些我们都不能控制，怎么TDD啊？
这些疑问是针对如何测试本身来讲的，不是针对TDD的。这点要弄清楚，千万不要弄混！
在中国，影响TDD实施的主要原因之一，就是很多程序员不知道如何做测试，非常多的程序员根本没有测试的概念，他们的想象力很丰富（或者说感觉很 好？），总是以自己的猜测来判断自己是否真的已经完成了某个功能或需求，但提交给QA之后的一分种内就会接二连三的收到惊人数量的bug回馈（不是开玩 笑，真有这样的事情不断的发生），如果你是一名这样的程序员，请检讨，因为你根本不合格。
所以请注意，想要用TDD请首先学会测试的基本功（说到这里可能又有人“懒惰”了），另外要养成没有测试过的功能坚决不算结束的功能的习惯，这个习惯很重要。为什么TDD狂热者能够report出极少数量的bug的原因之一，就是要养成经常性测试的习惯。
又跑题了，总结一下，这篇Blog的目的就是要让大家清楚什么是TDD，TDD不是测试方法，是编码流程。测试遇到的问题要在测试中解决，不会测试 是影响TDD实施的主要问题之一。那么在接下来的Blog中我会举例说明一下如何做测试：如何为有数据访问的应用程序写测试，如何为有Web交互的应用程 序写测试，简单地说就是如何为有外部依赖的程序写测试。另外我还将阐述一下写测试时可以应用的几种手段等类似的测试技巧。
