如果使用“Virtual and Override”手法来伪造合作者类，那么不存在任何问题，我们可以用下面的图来表示。

　　另一方面，如果想使用“接口提取”手法的话，那么一种比较好的策略是使用“外覆类”（Wrapper Class），如下图所示。

　　2.6 当CollaboratorClass是标准类库的一员时，怎么办？

　　有些时候，我们的被测类所依赖的是特定操作系统（Windows， Unix， 或Mac）、特定标准规范（.NET，或J2EE）、特定函数库或类库（如POSIX API和Win32 API）及特定用户界面（CUI或者GUI）所提供的功能时，这实际上是引入了对特定平台的依赖性，而这往往都是在提示我们：应该加入一个更高层次的抽象（也即一个间接层，indirection），从而将这种对特定平台的依赖隐藏到这个抽象之后。换句话说，我们应该引入一个接口，来使我们的代码具有平台无关性，如下图所示。

　　2.7 怎样测试抽象接口？

　　假设我们的系统中定义了一个抽象接口ServiceInterface，系统中有两个类（分别是ServiceImpl1和ServiceImpl2）实现了这个接口。现在，我们希望为ServiceInteface抽象接口编写一个通用的测试类，这个测试类不仅能测试当前已经实现该接口的类，而且可以不加修改地应用于将来实现ServiceInteface接口的类。应该怎么办呢？下图展示了一种可能的方案。

　　上图中，ServiceInterfaceTestFixture测试类中的测试方法都是基于ServiceInterface来进行测试的，不依赖于其具体实现类。这样就保证了仅测试抽象接口所定义的行为。当将来系统引入ServiceInteface的新的实现类时，只需要从ServiceInterfaceTestFixture类再派生出一个新子类，并实现createServiceInstance()方法来创建相应的对象即可。

相关链接：