一引言
测试驱动开发在减少开发努力的同时也改进了软件的开发质量单元测试作为一整套测试策略的基础必须是全面的且要求易于建立和执行迅速然而对执行环境和被测试类外部代码的依赖性使我们实现这些目标变得更为复杂例如把应用程序发布到容器将显着地延长代码和测试的周期而对其它类的依赖性通常也会导致测试的建立更加复杂和测试运行速度更为缓慢
集成两个流行的测试框架（StrutsTestCase和EasyMock）来单元测试Struts应用程序将会更为容易地建立测试并加快测试速度然而这两个框架之间尚存在一些隔阂从而很难把它们理想地集成到一起在本文中我将通过分析两种方案（一个面向对象的方案和一个面向方面的方案）来探讨这个问题同时我还将展示面向方面编程(AOP)是如何通过简化一些看起来很困难的问题的解决方案而进一步补充面向对象编程(OOP)的
二集成需要
一个典型的Struts应用程序既能够展示也其所使用的执行环境也会体现出类之间的依赖性问题这是因为Struts行为（Action）是在一个servlet容器内执行的并且典型情况下会调用其它的类来处理请求模拟对象测试方法有助于消除其中不必要的依赖性借助于继承自基本JUnit测试集的MockStrutsTestCase类StrutsTestCase测试框架提供了对servlet容器的一种模拟实现这显然方便了容器外测试因而也相应地加快了单元测试周期另一方面另一个测试框架—EasyMock—进一步便利了对协作类的动态模拟（Mock）这个框架中所提供的模拟能够用更简单的实现来代替真正的类并且添加了校验逻辑以支持单元测试
非常清楚把这两个框架结合在一起是非常有益的—Struts应用程序便可以在非常真实的隔离环境下进行测试理想情况下你需要使用下列步骤来实现这样的一个单元测试
建立MockStrutsTestCase以便模拟servlet容器
借助于EasyMock来模拟行为所依赖的类
设置模拟的期望值
把模拟注入到当前测试的行为中
继续进行测试和校验
注意上面步骤中所执行的依赖性注入使被测试的Struts行为远离了其真实的协作者而与一个模拟的行为进行交互为了把通过EasyMock生成的模拟注入到行为中你需要从测试类内部存取这些行为相应的实例遗憾的是这里出现了一种障碍因为我们无法轻易地从MockStrutsTestCase中实现这样的存取
三OOP方案
那么你该如何从MockStrutsTestCase中存取行为实例呢？首先让我们来分析一下MockStrutsTestCase和Struts的控制器组件之间的关系
图中展示的关键关系有可能潜在地导致一种解决上面问题的方案
图此处展示的关系能够建立一种OOP方案
MockStrutsTestCase中提供了一个public类型的getter方法用于检索ActionServlet
ActionServlet有一个protected类型的getter方法用于实现RequestProcessor
RequestProcessor把行为实例存储为一个protected类型的成员
你是否可以子类化ActionServlet和RequestProcessor从而使MockStrutsTestCase能够存取行为呢？相应的结果调用链看上去应该如下所示
注意在你分析完把MockStrutsTestCase链接到Struts行为的调用序列图之后你就会发现此方法是行不通的
图展示了存在于MockStrutsTestCase和Struts组件之间的关键性交互
图存在于MockStrutsTestCase和Struts组件之间的交互
图展示的问题涉及到Struts行为创建的时序问题到行为内部的模拟注入必须在调用MockStrutsTestCaseactionPerform()之前发生然而此时这些行为还不可用因为只有在调用actionPerform()后Requ
estProcessor才能够创建这些行为实例
既然你不能很容易地把行为实例传播到MockStrutsTestCase中那么为什么不子类化RequestProcessor并重载processActionCreate()方法呢？在这个重载方法中你可以存取所有的行为实例这样以来创建配置和设置对相应行为实例的一个模拟一下子变得非常直接因为应该在执行完actionPerform()之后调用MockControlverify()方法所以你还需要重载processActionPerform()以进行此校验调用
这种方案对于测试正规的Struts应用程序是不太适合的因为即使所有的行为仅与单个模拟进行交互测试一个行为也有可能要求多个测试方法—每个方法都具有不同的模拟期望为此我们建议的方案是创建不同的RequestProcessor子类相应于每个子类设置不同的模拟期望另外还需要多个Struts配置文件来指定不同的RequestProcessor子类最终管理大量的测试将成为一件令人头疼的事情
四AOP方案
因此我们非常希望在执行某行为之前能够通过某种方式实现在MockStrutsTestCase中使用该行为的实例如果你熟悉AOP那么你会立即意识到它所提供的简单方案即能直接满足这一要求注意这里的关键是定义一个切点由它负责捕获行为执行连接点然后通过一个before advice把模拟注入到相应的行为中
在此我选择使用AspectJ框架来实现这一方案当然其它的例如Spring AOP这样的AOP实现也应该能够良好工作不过Spring AOP还需要一个额外的步骤—通过Spring框架中的DelegatingActionProxy类把对Struts行为的管理委托给Spring
图展示了基于AOP方案的单元测试示例静态模型
图基于AOP方案的单元测试示例静态模型
SimpleAction是一个Struts行为的子类同时与ActionService进行协作其中SimpleActionTest派生于MockStrutsTestCase用来测试SimpleAction
SimpleActionTest使用EasyMock创建和建立一个模拟ActionServiceSimpleActionTest还实现StrutsActionPreExecuteListener接口以便在即将运行 SimpleAction的execute方法时接收通知作为通知的一部分SimpleActionTest接收SimpleAction实例以便注入ActionService模拟由方面类StrutsActionPreExecuteNotifier负责通知任何实现监听器接口的测试类并且使相应的行为实例可用
下面的步骤描述了实现StrutsActionPreExecuteNotifier的过程
◆首先由一个切点选择相应的测试方法执行连接点另一方面这个测试方法驻留于负责监听该行为的预执行事件的测试类中另外这个切点还会暴露当前执行的测试类对象 pointcut mockStrutsTest(StrutsActionPreExecuteListener actionTest):
◆然后由第二个切点负责捕获上面的行为执行连接点通过结合第一个切点匹配范围被限制到该行为相应的测试方法的调用流程的内部这种进一步缩小的范围对行为执行（并非通过测试方法激活）起到过滤作用最终方面根本不会影响到最后生成的代码该行为及其相应的测试类实例都是经由切点参数加以暴露的 pointcut strutsActionExecute(Action action StrutsActionPreExecuteListener actionTest):
◆最后由一个与前一个切点相关联的before advice负责通知测试类（它们担任行为事件的监听器）并且传递相应于模拟注入的行为实例
图展示了这些类之间的动态交互情形
图类之间的动态交互
注意图中从行为到方面的虚线描述了对行为执行连接点的捕获情况此时序图与第一个时序图比较其重要区别正在于行为执行之前发生的三个步骤
一个切点捕获行为执行连接点（由从SimpleAction指向StrutsActionPreExecuteNotifier的虚线箭头指出）
方面的before advice负责通知测试类并且把相应的行为实例传递给它
测试类把模拟对象注入到即将要开始执行的行为实例中
现在你可以基于前面概括的五个步骤继续编写行为测试下面的代码展示了相应于SimpleActionTest的部分代码步骤已在注释中标出
使用MockStrutsTestCase和EasyMock进行行为测试的部分代码
在行动及其依赖的服务之间存在四种可能的复合关系
每个行为依赖于一个服务
每个行为依赖于多个服务
多个行为依赖于一个服务
多个行为依赖于多个服务
我在此展示的方案能够比较灵活而且相对容易地支持上面所有这四种情形因为模拟创建期望值建立以及模拟注入都能够在单个的测试类内实现
你能够不借助于监听器接口就可以在StrutsActionPreExecuteNotifier内部模拟注入吗？这看起来似乎使得测试类实现更简单一些然而实践证明类似早些时候讨论的OOP方案编写多个方面以创建不同的模拟对象并建立相应的不同的模拟期望是非常必要的另外在单个测试类内本地化模拟的创建与安装（借助于监听技术这是可能的）将变得更为方便
五总结
对于我们在本文中所讨论的集成问题有人可能会创造出一套相当不错的OOP方案然而构造这种方案很可能需要对Struts和StrutsTestCase有深入的理解才行并且要付出相当的努力影响本文中所讨论的两个测试框架（StrutsTestCase和EasyMock）紧密集成的主要障碍在于在Struts行为实例执行之前很难实现对它的访问在认识了导致这种障碍的基本原因之后AOP方案自然地出现在我们面前不必再强求于基于传统型OOP的那种更复杂的方案AOP允许我们把我们的方案更为紧密地映射到问题空间
其实AOP的真正魔术在于它的连接点模型它能够使你穿越中间对象（例如ActionServlet和RequestProcessor）进而直指问题的核心借助于AOP技术中确定横切关注点这种非常节俭的方法开发者即能够设计出非常直观而且更为简单的解决方案AOP这种强有力的编程方法正好弥补了传统型OOP编程中所存在的不足如果被恰当用于解决适当类型的问题那么AOP有助于改进代码的模块化最终会产生出更为清晰和更易于理解的代码最后非常希望本文不仅有助于你的Struts应用程序的单元测试而且还吸引你进一步探讨AOP编程所体现出来的其它重要优点
