1. 反映真实需求

这里存在先写测试和后写测试的区别。

先说后写测试。根据很多经验，在直接写产品实现代码时，需要考虑需求，同时需要兼顾实现的细节，用什么算法和语法。在对需求和考虑和实现细节间来回，很容易让人产生对其中一方的疏忽，遗漏掉一些需求方面，甚至在实现上存在缺陷。

有人会说我可以通过后写测试来保证。第一经验是，很多人都不会在实现完成后，补充测试，因为还有更多的工作和需求需要实现。第二是开发人员很容易在后补的测试中，只是试图去测试他已有的实现，而不是需求本身，很容易遗漏掉一些边界检查之类，在测试时，已有的实现细节会在脑子里面先入为主，即使实现存在问题或有漏洞，也很难在后补的测试中测出来。我阅读过很多面试者的测试代码，很明显都是后补的，因为一些很明显的问题没有测出来，甚至已经实现的逻辑也是只测试了一部分。而这些面试者都承认。

结果就是，一旦代码签入，开始集成之后，暴露出问题，后补的测试起不到对于实现代码的保障需求的作用，开发者不能不借助调试工具，单步跟踪实现代码的每一行去寻找问题发生的原因。

再说先写测试。按照TDD的流程，先写失败的测试，再写恰好让测试成功的实现代码，最后重构，如此往复。这样的好处在于，每先写一个测试，都是在试图用自己对问题和需求的理解，来定义实现代码的架子。从测试的不同角度，范围、边界、大小、功能等等，来定义实现代码将来会是个什么样子。一个测试接着一个测试，利用TDD的过程，把实现代码恰好不多不少，正好驱动出解决这个需求和问题的实现代码来。

这里的重点在于，先写测试可以让开发者把重点放在理解需求和实现需求上，而不是一开始就陷入实现的细节中同时兼顾需求，掉入两者都兼顾不好的境地。先写的测试代码，作为副产品，可以作为验证需求的得力保障。

2. 设计在其中

先写测试对于设计的好处在于，先写测试先定义新的类，以及定义类与类之间的关系，就是在定义类与类之间如何交互，每个类如何暴露自己的接口，类和类之间的引用关系。这时，测试代码会逼迫开发者认真考虑如何分解类与类之间的耦合关系，这样产生的实现代码更容易利用了IoC和DIP的模式，实现面向接口编程。

这样实现代码的好处还在于，代码的可测试性很高，在加入更多的测试代码和新类的时候，同样借力于已有类的面向接口和依赖反转所带来的可测试性，达到新实现代码的面向接口和可测试性，这样进入良性循环。而这对于整体的代码和设计，获益良多。换句话说，测试即设计。

回头看后写测试的情况，因为从一开始开发者把重心放在实现的细节和功能需求的往复上，对于代码设计、类的关系和定义很容易疏于考虑，产生的结果可能是耦合紧，可测试性差。

3. 增强信心

在我看来，软件开发周期、软件交付最大的问题在于交付后的运行和维护阶段，正是这个阶段才是软件在持续交付价值的时期。在软件的可维护性，在这个阶段凸显价值。在软件交付后，包括软件开发周期期间，不可避免的就是开发者在根据新的需求，逐渐添加新的功能代码，或者修复一些已知的缺陷。

很多经验表明，在开发者按照需求添加一些新的代码进入系统，或者试图修复已有缺陷时，很容易导致既有功能出错，也就是新引入的代码打破了既有代码的逻辑，导致回归问题的出现。因为软件系统的可测试性差，无法做到快速频繁自动的回归测试，带来的可维护性自然也很差。

而作为TDD的副产品之一——可以快速频繁自动运行的测试代码，可以在开发者新引入代码之际，给予开发者足够的信心，每次添加一点新代码，一个方法，一个类，都已频繁运行已有相关的测试代码，来确保新引入代码不会打破已有的功能。

在持续集成中，这些测试代码可以帮助验证每次签入的代码都不会破坏掉已有的功能。这也是《重构》里面反复提到的在每个重构小步骤后都要运行所有的测试代码的原因所在。

4. 粒度和进度

按照TDD的原则，先写测试，可以让开发者在同一时间只关注在功能需求的一小部分，把功能需求且分到一定小的粒度，用测试代码去表示这样的需求，用实现代码让测试通过，实现这样的需求，然后重构。

这样的好处在于，开发者自己的注意力和重心不用在整个功能需求内的小需求点之间犹豫，每次注重解决单个小问题，解决完一个进入下一个小问题的解决。在保证小粒度实现的同时，保证进度可以随时被打断，但同时被打断时已经做完的是完整可以运行，至少是实现了部分需求的实现代码。

而后写测试的代价是，首先实现代码很有可能包含设计上的问题，甚至含有缺陷，在完美的测试代码完成之前（事实上这是不可能的），可以交付的是可能存在严重缺陷，甚至是曲解了功能需求的实现代码。