利用测试概念进行代码设计时的七条基本原则[1]

　　利用测试概念进行代码设计时的七条基本原则[1]   软件测试

　　当设计大型程序的时候，您必须时刻留心不同设计选项对诸如性能和可扩展性这样的特征的影响。随着软件产品的日渐复杂及其无所不在的部署，软件的“可测试性”也成了更重要的考虑事项。

　　彻底测试代码的重要性是显然的。花在编写测试和测试代码上的时间和精力给您带来的回报是维护成本的大幅降低。

　　然而，除非您很小心，否则您花在测试代码上的精力可能会首先达到花在编写代码上的精力的几倍!我曾看到程序员们齐心协力地对他们的全部代码进行单元测试，结果花在上面的时间使大多数人都以沮丧而告终。

　　幸运的是，没有必要这样。在您设计软件的时候应用一些基本原则，编写易于测试、甚至使测试成为乐趣的代码是可能的。

　　跟其它编码原则一样，这些原则也不是不容置疑或不可改变的教条。有时候打破这些规则也是必要的。因此，理解每条原则背后的动机和判断何时这些动机不适用(或应让位给更关心的问题)的能力是很重要的。

　　原则 1. 到 GUI 视图的外面去

　　尽可能把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。为什么您需要这样做呢?

　　对 GUI 测试者来说，通过方法调用测试功能比间接地测试功能容易的多。

　　另一个好处是它使修改程序功能而不影响视图变的更容易。

　　当然，视图中也可能存在错误。在理想情况下，对程序的测试将同时检查模型和视图。(想更多了解测试视图，请参阅我关于 Liar View 错误模式的文章或 Jeffries 等人的 Extreme Programming Installed。这两个链接都在参考资料部分。)

　　原则 2. 使用类型进行错误检查

　　类型是您的朋友 — 尽可能多地用类型系统自动检查错误。

　　类型能在程序运行之前自动捕捉程序中的错误。没有静态类型检查的话，类型错误将作为破坏者逗留在您的程序中，直到恰当的执行路径碰巧把它揭露出来为止。

　　最大限度地发挥使用类型的长处是棘手的。通常，一组数据结构可以在一个抽象级别上一起使用，或者被分出，成为一个单一的、更高抽象级别的一个新的相关数据类型。

　　事实上，编程语言自身的历史可以看成是可以编程的抽象级别的逐渐提高。汇编语言提供了比特到整数和浮点数的抽象。接下来是记录和函数抽象，然后又是诸如对象、类、线程以及异常这样的抽象。

　　在每一抽象级别上，达到与更高级别抽象一致的功能是可能的，但那实质上仅仅是耗费更多精力，冒更多的错误风险。

　　在面向对象语言(其它现代语言也一样)中，一个程序员在设计抽象上有很大的灵活性。在哪个抽象级别上设计程序就成了基于折衷的决定，比如由抽象级别提供的更多的健壮性和由于不能在更低抽象级别上工作而带来的表达性(有时是性能)的损失。

　　通常，高级别抽象带来的健壮性和简单性的价值很少被其它考虑事项超过。(要了解对这个问题的更多讨论，请参阅我关于 Impostor Type 错误模式的文章，在参考资料部分有它的链接。)

　　原则 3. 使用调节器避免“故障线路”(fault line)

　　我用“故障线路”来指独立组件之间的接口，独立组件之间和组件与其相应子组件之间相比，很少有交互。这种故障线路的一个典型示例是 GUI 视图和它的模型之间的接口。其它示例包括在编译器中处理的不同阶段之间的接口或操作系统的内核和用户界面之间的接口。

　　找出程序的故障线路，然后用具有转发功能的调节器快速访问聚合组件。

　　沿着故障线路隔离测试每个组件通常更容易。但如果每个组件暴露的对象有很多，或者组件中您想测试的一些对象只有通过多个嵌套引用才能访问，那么测试就会变的很乏味。

原文转自：http://www.ltesting.net