副标题#e#
当设计大型措施的时候，您必需时刻把稳差异设计选项对诸如机能和可扩展 性这样的特征的影响。跟着软件产物的日渐巨大及其无所不在的陈设，软件的“ 可测试性”也成了更重要的思量事项。
彻底测试代码的重要性是显然的。花在编写测试和测试代码上的时间和精神 给您带来的回报是维护本钱的大幅低落。
然而，除非您很小心，不然您花在测试代码上的精神大概会首先到达花在编 写代码上的精神的几倍！我曾看到措施员们齐心合力地对他们的全部代码举办单 元测试，功效花在上面的时间使大大都人都以沮丧而了却。
幸运的是，没有须要这样。在您设计软件的时候应用一些根基原则，编写易 于测试、甚至使测试成为兴趣的代码是大概的。
跟其它编码原则一样，这些原则也不是不容置疑或不行改变的教条。有时候 冲破这些法则也是须要的。因此，领略每条原则背后的念头和判定何时这些念头 不合用（或应让位给更体贴的问题）的本领是很重要的。
原则 1. 到 GUI 视图的外面去
尽大概把代码移到 GUI 视图的外面。然后各类 GUI 行动就能成了模子上的 简朴要领挪用。为什么您需要这样做呢？
对 GUI 测试者来说，通过要领挪用测试成果比间接地测试成果容易的多。
另一个长处是它使修改措施成果而不影响视图变的更容易。
虽然，视图中也大概存在错误。在抱负环境下，对措施的测试将同时查抄模 型和视图。
原则 2. 利用范例举办错误查抄
范例是您的伴侣 ― 尽大概多地用范例系统自动查抄错误。
范例能在措施运行之前自动捕获措施中的错误。没有静态范例查抄的话，类 型错误将作为粉碎者停留在您的措施中，直到得当的执行路径可巧把它揭破出来 为止。
最大限度地发挥利用范例的优点是棘手的。凡是，一组数据布局可以在一个 抽象级别上一起利用，可能被分出，成为一个单一的、更高抽象级此外一个新的 相关数据范例。
事实上，编程语言自身的汗青可以当作是可以编程的抽象级此外逐渐提高。 汇编语言提供了比特到整数和浮点数的抽象。接下来是记录和函数抽象，然后又 是诸如工具、类、线程以及异常这样的抽象。
在每一抽象级别上，到达与更高级别抽象一致的成果是大概的，但那实质上 仅仅是淹灭更多精神，冒更多的错误风险。
在面向工具语言（其它现代语言也一样）中，一个措施员在设计抽象上有很 大的机动性。在哪个抽象级别上设计措施就成了基于折衷的抉择，好比由抽象级 别提供的更多的结实性和由于不能在更低抽象级别上事情而带来的表达性（有时 是机能）的损失。
凡是，高级别抽象带来的结实性和简朴性的代价很少被其它思量事项高出。
原则 3. 利用调理器制止“妨碍线路”（fault line）
我用“妨碍线路”来指独立组件之间的接口，独立组件之间和组件与其相应 子组件之间对比，很少有交互。这种妨碍线路的一个典范示例是 GUI 视图和它 的模子之间的接口。其它示例包罗在编译器中处理惩罚的差异阶段之间的接口或操纵 系统的内核和用户界面之间的接口。
找出措施的妨碍线路，然后用具有转发成果的调理器快速会见聚合组件。
沿着妨碍线路断绝测试每个组件凡是更容易。但假如每个组件袒露的工具有 许多，可能组件中您想测试的一些工具只有通过多个嵌套引用才气会见，那么测 试就会变的很乏味。
不消断绝测试，而是拥有您在它上面挪用您想测试的各类要领的单个调理器 工具凡是是有辅佐的。这个工具然后能把这些要领挪用转发到适当的处所。
沿着沟通线路，设计和本身的测试代码串联在一起的措施组件接口是有益的 。这将使您把留意力会合在使这些接口尽大概简朴上。
#p#副标题#e#
原则 4. 要领：小型签名和缺省参数
利用小型要领说明和重载带缺省要领参数的要领将使您在测试中挪用这些方 法变的愉快的多。不然，在测试这些要领时您将不得不结构特别参数。假如参数 很大，那么将很快导致代码膨胀。更糟的是，它会诱使您编写比在其它环境下更 少的测试。
原则 5. 会见器不该修改内存状态
请在您的测试中利用不修改内存状态的会见器来查抄工具状态。
在某些方面，测试和尝试室试验相似。它们都想证明特定假设有效。假如特 定查抄行动改变了该规模的状态，那么要这样做会变得坚苦的多。
与量子力学规模差异，计较机历程的状态可以不修改就被查抄。利用这种原 则对您有长处。
原则 6. 用接口说明外部措施组件
用接口说明外部措施组件使得我们可以容易地在测试案例中模仿这些组件。
#p#分页标题#e#
这条原则能节减大量时间，出格是当外部组件的实现还未完成时。凡是，大 大都根基组件都不能准时可用。假如这些组件不在适当位置您就不能测试您本身 的代码的话，那么您就在朝劫难走去。您的客户不会体贴您只有两个小时来集成 迟到了两周的组件。他们知道的全部就是整套产物被延期了和这是违约的。
原则 7. 优先编写测试代码
优先编写测试代码。这是尺度的 XP 要领，但却总有一种忽视它的诱惑。
每次我屈服于这种诱惑时，我都感想反悔。假设您正尽力出产正确的代码， 那么您 好象能从推迟编写测试代码中节减的时间其实只是一个理想。
留意：这不是说您应该一次性编写全部测试代码后，再一次性全部实现。编 写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的 步伐。设计以这种方法得以希望；在实现阶段捕获错误并在下一组测试中纠正它 。以这种方法编写测试也更少会使人畏缩。
代码比您需要的还多？
只需一点点尽力，就大概容易地对任何措施举办彻底的测试。虽然，不行避 免存在这些原则不合用的环境；于是，看起来仿佛不行能对成果举办测试。
当呈现这些环境时，我极力退一步地看这个问题，“我奈何才大概测试这种 代码？”相反地，我问本身，“我奈何才气以可测试方法编写这些代码呢？”这 种想法上的改变的功效常常是增加了大量 仅仅处事于简化测试的成果。
什么？别担忧；呈现这种环境完全正常。
就象许多现有的设计模式，它们只是为了增加措施的可扩展性就往措施中添 加许多类（譬喻 visitor、decorator 等等），开拓简化测试的新模式是可以接 受的。实际上，面向工具语言的许多特征都是为了简化扩展而包括进去的；为什 么语言的将来版本（或全新的语言）不该包括简化测试的特征。
对 Java 语言来说，这已经开始。人们打算在将来版本中包括许多更强大的 范例系统、断言（assertion）等等。就象面向工具的语言已经增加了我们重用 和扩揭示有代码的水平，未来，面向测试的设计和特征将辅佐我们加强新老代码 的结实性。
