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子类。最终，管理大量的测试将成为一件令人头疼的事情。
文章来源于领测软件测试网 https://www.ltesting.net/
