必需的第一项更改是使测试类成为 RMock TestCase，而不是成为 jMock CGLIB TestCase。目的是在测试本身内启用属于 RMock 的那些模拟对象的较容易的配置并且 —— 更重要的是 —— 在初设置期间启用这些配置。经验证明，如果测试类扩展的整个 TestCase 对象属于 RMock，则通过两个框架构造和使用模拟对象将更容易。此外，乍看之下，快速确定模拟对象的流程将更容易一些（在这里，流程 用于描述使用模拟对象作为参数甚或作为其他模拟对象的返回类型的情况）。
必需的第二项更改是（至少）构造一个保存传递给 Collaborator 类的构造函数的参数实际值的对象数组。为了清晰起见，还可以包括构造函数接受的类类型的类型数组并可以传递该数组，以及刚刚描述为参数的对象数组以实例化模拟 Collaborator 对象。
第三项更改涉及用正确语法构造对 RMock 模拟对象的一个或多个期望。而第四项也是后一项必需的更改是使 RMock 模拟对象脱离记录状态转入绪状态。
实现 RMock 更改
清单 9 显示了对 ServiceClassTest 类的终修改。它还显示了 RMock 及其相关功能的引入。
清单 9. 修正场景 3 的 ServiceClassTest 类
...
import com.agical.rmock.extension.junit.RMockTestCase;
public class ServiceClassTest extends RMockTestCase {
private ServiceClass serviceClass;
private Collaborator collaborator;
public void setUp(){
serviceClass = new ServiceClass();
Object[] objectArray = new Object[]{"exampleString"， 5};
collaborator =
(Collaborator)intercept(Collaborator.class， objectArray， "mockCollaborator");
}
public void testRunServiceAndReturnFalse(){
collaborator.executeJob();
modify().returnValue("failure");
startVerification();
boolean result = serviceClass.runService(collaborator);
assertFalse(result);
}
}
首先，需要注意测试的期望仍未改变。RMockTestCase 类的导入预示着引入 RMock 框架功能。接下来，测试类现在将扩展 RMockTestCase，而不是 MockObjectTestCase。稍后，我将向您展示在 TestClass 对象仍为 RMockTestCase 类型的对象的测试用例中重新引入 MockObjectTestCase。
使用 intercept() 方法的备选方法
通过 RMock，您可以使用 intercept() 方法仅模拟具体类。可以使用 RMock mock() 方法模拟具体类和接口。仅当需要模拟那几个重要方法时，使用 interface() 方法。此方法被视为经过改进的 mock() 方法。
在 setUp() 方法内，用 Collaborator 类的构造方法所需的实际 值实例化对象数组。该数组被立刻传递给 RMock 的 intercept() 方法来帮助实例化模拟对象。方法的签名类似于 jMock CGLIB mock() 方法的签名，因为这两种方法将接纳惟一模拟对象标识符作为参数。模拟对象到 Collaborator 类型的类强制转换十分有必要，因为 intercept() 方法将返回类型 Object。
在测试方法本身 testRunServiceAndReturnFalse() 之内，您可以看到更多更改。模拟 Collaborator 对象的 executeJob() 方法将被调用。在此阶段，模拟对象处于记录状态 —— 即简单地定义对象将一直期望的方法调用，因此，模拟将相应地记录期望。下一行是对模拟对象的通知，用于确保当它遇到 executeJob() 方法时，它应当返回字符串 failure。因此，使用 RMock，您只需通过调用方法而不调用模拟对象（并传递它可能需要的任何参数）来描述期望，然后修改该期望以相应地调整任何返回类型。
后，调用 RMock 方法 startVerification() 把模拟 Collaborator 对象转为绪状态。模拟对象现已准备好在 ServiceClass 类中作为实际对象使用。该方法非常重要并且必须调用它才能避免测试初始化失败。
测试更改
再次重新运行 ServiceClassTest 以达到终的肯定结果：在模拟对象实例化期间提供的参数造成了所有差别。图 6 显示 JUnit 测试已经通过。
图 6. 使用 RMock 的场景 3 测试成功
assertFalse(result) 代码行表示与场景 1 相同的测试期望，而 RMock 像 jMock 以前那样维持测试成功。在许多方面，这都十分重要，但是这里更重要的特点可能是实践了修正失败测试的灵活 原则而不更改测试期望。惟一的差别是使用了另一个框架。
在下一个场景中，您将在一种特殊情况下使用 jMock 和 RMock。没有一个框架能够仅凭自身实现正确结果，除非在测试内形成某种联合。
场景 4：jMock 和 RMock 之间的特定协作
如前所述，我希望检验两个框架必须协同工作才能实现某个结果的情况。否则，构建良好的测试每次都将失败。在某些情况下，使用 jMock 还是 RMock 并不重要，例如，当需要模拟的接口或类存在于已经签名的 JAR 中时。此类情况十分少见，但是当测试针对安全专有的产品（通常是这样或那样的一类现有软件）中的应用程序编程接口 (API) 编写代码时可能会出现此情况。
清单 10 显示了两个框架完成测试用例的示例。
