必需的第一項更改是使測試類成為 RMock TestCase，而不是成為 jMock CGLIB TestCase。目的是在測試本身內啟用屬于 RMock 的那些模擬對象的較容易的配置并且 —— 更重要的是 —— 在初設置期間啟用這些配置。經驗證明，如果測試類擴展的整個 TestCase 對象屬于 RMock，則通過兩個框架構造和使用模擬對象將更容易。此外，乍看之下，快速確定模擬對象的流程將更容易一些（在這里，流程 用于描述使用模擬對象作為參數(shù)甚或作為其他模擬對象的返回類型的情況）。
必需的第二項更改是（至少）構造一個保存?zhèn)鬟f給 Collaborator 類的構造函數(shù)的參數(shù)實際值的對象數(shù)組。為了清晰起見，還可以包括構造函數(shù)接受的類類型的類型數(shù)組并可以傳遞該數(shù)組，以及剛剛描述為參數(shù)的對象數(shù)組以實例化模擬 Collaborator 對象。
第三項更改涉及用正確語法構造對 RMock 模擬對象的一個或多個期望。而第四項也是后一項必需的更改是使 RMock 模擬對象脫離記錄狀態(tài)轉入緒狀態(tài)。
實現(xiàn) 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 框架功能。接下來，測試類現(xiàn)在將擴展 RMockTestCase，而不是 MockObjectTestCase。稍后，我將向您展示在 TestClass 對象仍為 RMockTestCase 類型的對象的測試用例中重新引入 MockObjectTestCase。
使用 intercept() 方法的備選方法
通過 RMock，您可以使用 intercept() 方法僅模擬具體類。可以使用 RMock mock() 方法模擬具體類和接口。僅當需要模擬那幾個重要方法時，使用 interface() 方法。此方法被視為經過改進的 mock() 方法。
在 setUp() 方法內，用 Collaborator 類的構造方法所需的實際 值實例化對象數(shù)組。該數(shù)組被立刻傳遞給 RMock 的 intercept() 方法來幫助實例化模擬對象。方法的簽名類似于 jMock CGLIB mock() 方法的簽名，因為這兩種方法將接納惟一模擬對象標識符作為參數(shù)。模擬對象到 Collaborator 類型的類強制轉換十分有必要，因為 intercept() 方法將返回類型 Object。
在測試方法本身 testRunServiceAndReturnFalse() 之內，您可以看到更多更改。模擬 Collaborator 對象的 executeJob() 方法將被調用。在此階段，模擬對象處于記錄狀態(tài) —— 即簡單地定義對象將一直期望的方法調用，因此，模擬將相應地記錄期望。下一行是對模擬對象的通知，用于確保當它遇到 executeJob() 方法時，它應當返回字符串 failure。因此，使用 RMock，您只需通過調用方法而不調用模擬對象（并傳遞它可能需要的任何參數(shù)）來描述期望，然后修改該期望以相應地調整任何返回類型。
后，調用 RMock 方法 startVerification() 把模擬 Collaborator 對象轉為緒狀態(tài)。模擬對象現(xiàn)已準備好在 ServiceClass 類中作為實際對象使用。該方法非常重要并且必須調用它才能避免測試初始化失敗。
測試更改
再次重新運行 ServiceClassTest 以達到終的肯定結果：在模擬對象實例化期間提供的參數(shù)造成了所有差別。圖 6 顯示 JUnit 測試已經通過。
圖 6. 使用 RMock 的場景 3 測試成功
assertFalse(result) 代碼行表示與場景 1 相同的測試期望，而 RMock 像 jMock 以前那樣維持測試成功。在許多方面，這都十分重要，但是這里更重要的特點可能是實踐了修正失敗測試的靈活 原則而不更改測試期望。惟一的差別是使用了另一個框架。
在下一個場景中，您將在一種特殊情況下使用 jMock 和 RMock。沒有一個框架能夠僅憑自身實現(xiàn)正確結果，除非在測試內形成某種聯(lián)合。
場景 4：jMock 和 RMock 之間的特定協(xié)作
如前所述，我希望檢驗兩個框架必須協(xié)同工作才能實現(xiàn)某個結果的情況。否則，構建良好的測試每次都將失敗。在某些情況下，使用 jMock 還是 RMock 并不重要，例如，當需要模擬的接口或類存在于已經簽名的 JAR 中時。此類情況十分少見，但是當測試針對安全專有的產品（通常是這樣或那樣的一類現(xiàn)有軟件）中的應用程序編程接口 (API) 編寫代碼時可能會出現(xiàn)此情況。
清單 10 顯示了兩個框架完成測試用例的示例。
