跟其它编码原则一样，这些原则也不是不容置疑或不可改变的教条。有时候打破这些规则也是必要的。因此，理解每条原则背后的动机和判断何时这些动机不适用(或应让位给更关心的问题)的能力是很重要的。
原则 1. 到 GUI 视图的外面去
尽可能把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。为什么您需要这样做呢?
对 GUI 测试者来说，通过方法调用测试功能比间接地测试功能容易的多。
另一个好处是它使修改程序功能而不影响视图变的更容易。
当然，视图中也可能存在错误。在理想情况下，对程序的测试将同时检查模型和视图。(想更多了解测试视图，请参阅我关于 Liar View 错误模式的文章或 Jeffries 等人的 Extreme Programming Installed。这两个链接都在参考资料部分。)
原则 2. 使用类型进行错误检查
类型是您的朋友 — 尽可能多地用类型系统自动检查错误。
类型能在程序运行之前自动捕捉程序中的错误。没有静态类型检查的话，类型错误将作为破坏者逗留在您的程序中，直到恰当的执行路径碰巧把它揭露出来为止。
最大限度地发挥使用类型的长处是棘手的。通常，一组数据结构可以在一个抽象级别上一起使用，或者被分出，成为一个单一的、更高抽象级别的一个新的相关数据类型。
事实上，编程语言自身的历史可以看成是可以编程的抽象级别的逐渐提高。汇编语言提供了比特到整数和浮点数的抽象。接下来是记录和函数抽象，然后又是诸如对象、类、线程以及异常这样的抽象。
在每一抽象级别上，达到与更高级别抽象一致的功能是可能的，但那实质上仅仅是耗费更多精力，冒更多的错误风险。
在面向对象语言(其它现代语言也一样)中，一个程序员在设计抽象上有很大的灵活性。在哪个抽象级别上设计程序就成了基于折衷的决定，比如由抽象级别提供的更多的健壮性和由于不能在更低抽象级别上工作而带来的表达性(有时是性能)的损失。
通常，高级别抽象带来的健壮性和简单性的价值很少被其它考虑事项超过。(要了解对这个问题的更多讨论，请参阅我关于 Impostor Type 错误模式的文章，在参考资料部分有它的链接。)
原则 3. 使用调节器避免“故障线路”(fault line)
我用“故障线路”来指独立组件之间的接口，独立组件之间和组件与其相应子组件之间相比，很少有交互。这种故障线路的一个典型示例是 GUI 视图和它的模型之间的接口。其它示例包括在编译器中处理的不同阶段之间的接口或操作系统的内核和用户界面之间的接口。
找出程序的故障线路，然后用具有转发功能的调节器快速访问聚合组件。
沿着故障线路隔离测试每个组件通常更容易。但如果每个组件暴露的对象有很多，或者组件中您想测试的一些对象只有通过多个嵌套引用才能访问，那么测试就会变的很乏味。
利用测试概念进行代码设计时的七条基本原则[2] 软件测试
不用隔离测试，而是拥有您在它上面调用您想测试的各种方法的单个调节器对象通常是有帮助的。这个对象然后能把这些方法调用转发到适当的地方。
沿着相同线路，设计和自己的测试代码串联在一起的程序组件接口是有益的。这将使您把注意力集中在使这些接口尽可能简单上。
原则 4. 方法：小型签名和缺省参数
使用小型方法说明和重载带缺省方法参数的方法将使您在测试中调用这些方法变的愉快的多。否则，在测试这些方法时您将不得不构造额外参数。如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使您编写比在其它情况下更少的测试。
原则 5. 访问器不应修改内存状态
请在您的测试中使用不修改内存状态的访问器来检查对象状态。
在某些方面，测试和实验室试验相似。它们都想证明特定假设有效。如果特定检查动作改变了该领域的状态，那么要这样做会变得困难的多。
与量子力学领域不同，计算机进程的状态可以不修改就被检查。使用这种原则对您有好处。
原则 6. 用接口说明外部程序组件
用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。
这条原则能节省大量时间，特别是当外部组件的实现还未完成时。通常，大多数基本组件都不能准时可用。如果这些组件不在适当位置您就不能测试您自 己的代码的话，那么您就在朝灾难走去。您的客户不会关心您只有两个小时来集成迟到了两周的组件。他们知道的全部就是整套产品被延期了和这是违约的。
原则 7. 优先编写测试代码
优先编写测试代码。这是标准的 XP 方法，但却总有一种忽视它的诱惑。
每次我屈服于这种诱惑时，我都感到后悔。假设您正努力生产正确的代码，那么您 好象能从推迟编写测试代码中节省的时间其实只是一个幻想。
注意：这不是说您应该一次性编写全部测试代码后，再一次性全部实现。编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误并在下一组测试中改正它。以这种方式编写测试也更少会使人畏缩。
代码比您需要的还多?
只需一点点努力，就可能容易地对任何程序进行彻底的测试。当然，不可避免存在这些原则不适用的情况;于是，看起来好像不可能对功能进行测试。
当出现这些情况时，我尽力退一步地看这个问题，“我怎样才可能测试这种代码?”相反地，我问自己，“我怎样才能以可测试方式编写这些代码呢?”这种想法上的改变的结果经常是增加了大量 仅仅服务于简化测试的功能。
什么?别担心;出现这种情况完全正常。
就象很多现有的设计模式，它们只是为了增加程序的可扩展性就往程序中添加很多类(例如 visitor、decorator 等等)，开发简化测试的新模式是可以接受的。实际上，面向对象语言的很多特征都是为了简化扩展而包含进去的;为什么语言的未来版本(或全新的语言)不应包含简化测试的特征。
对 Java 语言来说，这已经开始。人们计划在未来版本中包含很多更强大的类型系统、断言(assertion)等等。就象面向对象的语言已经增加了我们重用和扩展现有代码的程度，将来，面向测试的设计和特征将帮助我们增强新老代码的健壮性。