4.把模擬注入到當前測試的行為中。
5.繼續進行測試和校驗。
注意，上面步驟4中所執行的依賴性注入使被測試的Struts行為遠離了其真實的協作者而與一個模擬的行為進行交互。為了把通過EasyMock生成的模擬注入到行為中，你需要從測試類內部存取這些行為相應的實例。遺憾的是，這里出現了一種障礙，因為我們無法輕易地從MockStrutsTestCase中實現這樣的存取。
三、OOP方案
那么，你該如何從MockStrutsTestCase中存取行為實例呢？首先，讓我們來分析一下MockStrutsTestCase和Struts的控制器組件之間的關系。
圖1中展示的關鍵關系有可能潛在地導致一種解決上面問題的方案。
圖1：此處展示的關系能夠建立一種OOP方案 MockStrutsTestCase中提供了一個public類型的getter方法用于檢索ActionServlet。 ActionServlet有一個protected類型的getter方法用于實現RequestProcessor。 RequestProcessor把行為實例存儲為一個protected類型的成員。你是否可以子類化ActionServlet和RequestProcessor從而使MockStrutsTestCase能夠存取行為呢？相應的結果調用鏈看上去應該如下所示：
myActionTest.getActionServlet().getRequestProcessor().getActions().
注意，在你分析完把MockStrutsTestCase鏈接到Struts行為的調用序列圖之后，你就會發現此方法是行不通的。
圖2展示了存在于MockStrutsTestCase和Struts組件之間的關鍵性交互。
圖2：存在于MockStrutsTestCase和Struts組件之間的交互圖2展示的問題涉及到Struts行為創建的時序問題。到行為內部的模擬注入必須在調用MockStrutsTestCase.actionPerform()之前發生。然而，此時這些行為還不可用，因為只有在調用actionPerform()后，RequestProcessor才能夠創建這些行為實例。
既然你不能很容易地把行為實例傳播到MockStrutsTestCase中，那么，為什么不子類化RequestProcessor并重載processActionCreate()方法呢？在這個重載方法中，你可以存取所有的行為實例；這樣以來，創建、配置和設置對相應行為實例的一個模擬一下子變得非常直接。因為應該在執行完actionPerform()之后調用MockControl.verify()方法，所以，你還需要重載processActionPerform()以進行此校驗調用。
這種方案對于測試正規的Struts應用程序是不太適合的。因為即使所有的行為僅與單個模擬進行交互，測試一個行為也有可能要求多個測試方法—每個方法都具有不同的模擬期望。為此，我們建議的方案是：創建不同的RequestProcessor子類，相應于每個子類設置不同的模擬期望。另外，還需要多個Struts配置文件來指定不同的RequestProcessor子類。最終，管理大量的測試將成為一件令人頭疼的事情。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
