Question

有些代码比其他代码更容易测试。对于测试来讲理想的代码要有明确定义的接口，没有过多的状态或者其他的“设置”，并且没有很多需要审查的隐藏数据。

如果你写代码的时候就知道以后你要为它为写测试的话，会发生有趣的事情：你开始把代码设计得容易测试！幸运的是，这样的编程方式一般来讲也意味着会产生更好的代码。对测试友好的设计往往很自然地会产生有良好组织的代码，其中不同的部分做不同的事情。

测试驱动开发

测试驱动开发（TDD）是一种编程风格，你在写真实代码之前就写出测试。TDD的支持者相信这种流程对没有测试的代码来讲会做出极大的质量改进，比写出代码之后再写测试要大得多。

这是一个争论很激烈的话题，我们不想搅进来。至少，我们发现仅通过在写代码时想着测试这件事就能帮助把代码写得更好。

但不论你是否使用TDD，其结果总是你用代码来测试另一些代码。本章旨在帮助你把测试做得既易读又易写。

在所有的把一个程序拆分成类和方法的途径中，解耦合最好的那一个往往就是最容易测试的那个。另一方面，假设你的程序内部联系很强，在类与类之间有很多方法的调用，并且所有的方法都有很多参数。不仅这个程序会有难以理解的代码，而且测试代码也会很难看，并且既难读又难写。

有很多“外部”组件（需要初始化的全局变量、需要加载的库或者配置文件等）对写测试来讲也是很讨厌的。

一般来讲，如果你在设计代码时发现：“嗯，这对测试来讲会是个噩梦”，这是个好理由让你停下来重新考虑这个设计。表14-1列出一些典型的测试和设计问题：

另一方面，如果对于你的设计容易写出测试，那是个好现象。表14-2列出一些有益的测试和设计的特征。