沿着相同线路，设计和自己的测试代码串联在一起的程序组件接口是有益的。这将使您把注意力集中在使这些接口尽可能简单上。
原则 4. 方法：小型签名和缺省参数
使用小型方法说明和重载带缺省方法参数的方法将使您在测试中调用这些方法变的愉快的多。否则，在测试这些方法时您将不得不构造额外参数。如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使您编写比在其它情况下更少的测试。
原则 5. 访问器不应修改内存状态
请在您的测试中使用不修改内存状态的访问器来检查对象状态。
在某些方面，测试和实验室试验相似。它们都想证明特定假设有效。如果特定检查动作改变了该领域的状态，那么要这样做会变得困难的多。
与量子力学领域不同，计算机进程的状态可以不修改就被检查。使用这种原则对您有好处。
原则 6. 用接口说明外部程序组件
用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。
这条原则能节省大量时间，特别是当外部组件的实现还未完成时。通常，大多数基本组件都不能准时可用。如果这些组件不在适当位置您就不能测试您自己的代码的话，那么您就在朝灾难走去。您的客户不会关心您只有两个小时来集成迟到了两周的组件。他们知道的全部就是整套产品被延期了和这是违约的。
原则 7. 优先编写测试代码
优先编写测试代码。这是标准的 XP 方法，但却总有一种忽视它的诱惑。
每次我屈服于这种诱惑时，我都感到后悔。假设您正努力生产正确的代码，那么您 好象能从推迟编写测试代码中节省的时间其实只是一个幻想。
注意：这不是说您应该一次性编写全部测试代码后，再一次性全部实现。编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误并在下一组测试中改正它。以这种方式编写测试也更少会使人畏缩。
代码比您需要的还多?
只需一点点努力，就可能容易地对任何程序进行彻底的测试。当然，不可避免存在这些原则不适用的情况;于是，看起来好像不可能对功能进行测试。
当出现这些情况时，我尽力退一步地看这个问题，“我怎样才可能测试这种代码?”相反地，我问自己，“我怎样才能以可测试方式编写这些代码呢?”这种想法上的改变的结果经常是增加了大量 仅仅服务于简化测试的功能。
什么?别担心;出现这种情况完全正常。
就象很多现有的设计模式，它们只是为了增加程序的可扩展性就往程序中添加很多类(例如 visitor、decorator 等等)，开发简化测试的新模式是可以接受的。实际上，面向对象语言的很多特征都是为了简化扩展而包含进去的;为什么语言的未来版本(或全新的语言)不应包含简化测试的特征。
对 Java 语言来说，这已经开始。人们计划在未来版本中包含很多更强大的类型系统、断言(assertion)等等。就象面向对象的语言已经增加了我们重用和扩展现有代码的程度，将来，面向测试的设计和特征将帮助我们增强新老代码的健壮性。
文章来源于领测软件测试网 https://www.ltesting.net/