在我们使用一个新的类库或是学习一个新的知识点的时候，想得到的是什么？我想得到是例子代码，通过例子，看到效果，给我一个整体的感官认识。而其实是帮助文档。

　　在《领域驱动设计与模式实战》一书中，作者给TDD这样的一个描述：使用测试或示例来详细说明行为。

　　而且这些单元测试示例可以被反复用于多种用途。例如在开发过程中可用它们来查找缺失或不正确的行为。在重构时，测试起到安全网作用。开发完之后可以作为质量文档。

　　TDD中所使用的关键准则是重构。一开始的时候，你可能把一个需求用单元测试写出来，然后用代码去实现这些单元测试，然后运行，检验运行的结果是否正确。然后再适用重构优化解决方案，然后再运行单元测试检查是否有错误。当增加新的功能时，也是先增加对应的单元测试，按照上面的流程一步步走下来。当修改bug或使用或是因为功能的增加，需求的改变或是优化系统结构而进行的重构需要对代码进行修改时，修改后，也需要运行单元测试，保证修改后的代码准确无误。

　　当有人使用成功使用TDD之后，可能不会在愿意放弃他。我现在大的感受，是TDD给我的重构结果的正确性提供了保证。例如我有时候修改完一段代码之后，并不知道我修改的代码会对我程序的哪些地方会产生影响，这些地方既有我写的，也有团队的其他成员写的，这些我都不能保证，只能靠自己的记忆去找需要同步修改的地方。这照成了产生bug的几率特别高。而且很有可能修改了一个bug而又引起了其他的好几个bug。这样的时间太常见了。

　　所以我才那么肯定TDD，并推荐大家都使用。保证重构和bug修改后系统的正确性是我现在从TDD上得到和认识到的大好处。而且现在我也只处于使用单元测试对领域模型和领域逻辑的阶段，对于UI和数据库现在我还有没有掌握，不过好像有好的测试方案。并且UI上的测试基本上记时黑盒测试了，UI测试可以可以使用系统的系统化录脚本的方式代替。但是使用单元测试来测试数据持久化层是很有必要的。

　　之前我们也说过敏捷设计的简单性和灵活性，简单性如何保证？一是靠设计和开发人员的经验，另一个可以保证系统设计简单的是单元测试。因为在很多时候，我们写的代码并不是底层的通用类库，而是针对该项目的一些代码，这些代码基本上会在该项目中使用，所以能够满足该项目的使用，能保证设计的简单性，那如何提前知道系统将会怎么使用这些代码呢？那是单元测试，单元测试把系统如何使用者这些代码都很罗列出来，并测试的边界条件，以保证代码的正确性。

　　单元测试除了能够简化领域模型之外，他们之间的关联关系也能得到结构上的优化。例如有一个应用，你自己在写单元测试的时候，都感觉比较麻烦，蹩脚。当你给团队的其他成员使用这段代码的时候，你会想着他们能有什么好的体验吗？通过单元测试，先让自己感觉简单易用，然后再交付给别人。这在提高系统结构质量方面有很大的好处。这也给系统的设计和开发人员设了一道安检线，保证每个设计都是深思熟虑后的决定，而不是武断的下结论。