准备实践自动化测试的朋友可以看看这本书：XUnit Test Patterns——Refactoring Test Code，及其网站http://xunitpatterns.com/。估计国内还没有译本。书的内容不错，只是倾向于单元测试，还糅合了其它诸如“反测试模式”（文中称为bad smells，大概如同code complete里面描述的bad smells差不多，只是这里从自动化测试代码的角度而言）的内容。我对测试模式比较感兴趣，就采摘一些与大家共享。
自动化测试所吸引“技术流”程序员的一个地方，就是试图在产品可执行代码运行的时候插入测试代码，一方面程序员需要了解产品代码的实现，可以体现其技术价值，另一方面可以过过“黑客”的瘾，让自己的代码侵入产品的运行中。
当然这只是附带的小甜头而已，真正的目的还是为了更有效地找到产品的缺陷。模仿者模式（原文为Test Double）是各种为了自动化测试顺利进行而让测试代码与产品代码共同执行的测试模式：
◆ 哑对象
相互协作的多个组件，如果其中一个尚未完成但又不太依赖其中的功能，大可以创建一个除了接口一模一样以外不做任何事的组件，仅仅是为了让这些组件能够放在一起测试。这种组件被称为“哑对象”，例如：
一系列组件需要其中一个组件确定某个数据库是否存在来继续后边的逻辑，为了让测试尽早进行，可以创建一个组件，单单返回数据库已经存在的信息。
◆ 伪对象
伪对象比哑对象要复杂一些。为了完成测试而创建的组件需要表现一定的行为，但是又不能实现如同产品一样的功能，所以需要用相对简单很多的实现来做到这一点。伪对象可以被看作是以作弊的方式实现需要的行为。例如为了计算出某个数值需要复杂运算，但是如果下游使用这个数值的组件只对其做简单判断，那么伪对象只需要返回预先指定的数值就可以测试下游组件的逻辑了。
◆ 测试桩
产品代码执行过程中需要某些条件的配合才能执行到某些分支，例如网络连接丢失的时候错误处理的逻辑。为了实现这些条件可能需要比较大的代价，但是如果能替换某个组件，使得正常情况下这个组件的功能与产品功能一样，需要测试的时候实现指定的条件，那么这个被称为测试桩的组件就可以让产品轻易执行到那些分支了。例如：
进行网络通信的组件可以替换为测试桩，这个测试桩在自动化测试程序需要的时候返回网络连接丢失的信息，这样从外部就可以检验错误处理的正确性了。
◆ 嗅探桩
很多产品的功能是通过用户界面来表达的，但为了调试缺陷或者更早发现产品内部通信上的缺陷，可以引入测试桩组件。它的作用不是实现指定的条件，而是把产品内部通信的数据留存一份，留待调试或者后期分析使用。例如：
ASP.Net应用程序存在浏览器与web服务器之间的通信，嗅探桩能够记录两者之前的所有http通信，取得这些信息有助于调试缺陷和自动分析用户界面上看不到的缺陷。
◆ 仿制对象
仿制对象比伪对象更复杂，相对于产品功能来说仿制对象的功能可能只是性能或者伸缩性上的差别。例如，如果安装服务器端的代价太大，为了测试客户端，服务器的仿制对象可能是实现全部与客户端的通信协议，与真实服务器端的区别可能是无须服务多个客户端，客户端需要的数据无须依赖其它组件而已。所以使用这个模式的前提是性价比足够高以及通信协议变动有限。
相关链接：
