基于Mock对象和AOP技术进行Struts应用程序单元测试开发

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



















本文转自朱先忠老师51CTO博客,原文链接: http://blog.51cto.com/zhuxianzhong/60131 ,如需转载请自行联系原作者

相关文章
|
5天前
|
机器学习/深度学习 敏捷开发 人工智能
探索自动化测试的前沿技术与实践挑战
【7月更文挑战第8天】随着信息技术的飞速发展,软件测试领域正经历着前所未有的变革。自动化测试作为提升测试效率、确保软件质量的重要手段,其前沿技术与实践挑战备受关注。本文深入探讨了自动化测试的最新进展,包括人工智能在测试用例生成中的应用、持续集成/持续部署(CI/CD)流程中的自动化策略、以及云测试平台的兴起。同时,文章分析了自动化测试实施过程中遇到的主要挑战,如环境配置的复杂性、测试用例的维护问题和跨平台测试的困难,并提供了相应的解决策略。通过案例分析,展示了成功实施自动化测试的关键因素,为软件测试专业人员提供了宝贵的参考和启示。
18 2
|
3天前
|
机器学习/深度学习 敏捷开发 人工智能
现代软件测试技术的演进与应用
随着软件行业的快速发展,软件测试技术也在不断演进和创新。本文探讨了现代软件测试技术的最新趋势和应用,包括自动化测试、持续集成与持续交付、AI在测试中的应用等方面。通过分析这些技术的发展,我们可以更好地理解如何提高软件质量、加速交付,并提升开发团队的效率和创新能力。 【7月更文挑战第10天】
10 3
|
3天前
|
前端开发
什么是 Mock 测试?
Mock 是在前后端分离开发中,用于模拟后端数据的工具,让前端能提前开发而无需等待真实接口。它的重要性在于加速协同开发,避免因数据延迟导致的阻塞。通过工具如 Apifox,可以创建请求,设定 Mock 参数和测试脚本,进行 Mock 测试以确保数据符合预期。了解 Mock.js 语法有助于更好地进行 Mock 测试。
|
5天前
|
安全 物联网 物联网安全
物联网设备的安全性评估与测试:技术深度解析
【7月更文挑战第7天】物联网设备的安全性评估与测试是保障物联网系统安全运行的重要环节。通过实施全面的安全性评估与测试,可以发现并修复设备中存在的安全漏洞和风险,提高整体安全防护能力。然而,由于物联网设备的多样性和复杂性以及安全标准与监管的缺失等挑战,测试工作需要不断创新和优化。未来,随着技术的不断进步和实践的深入,物联网设备的安全性评估与测试将更加完善和高效。
|
10天前
|
安全 测试技术 网络安全
网络安全中的渗透测试与风险评估:技术深度解析
【7月更文挑战第3天】在网络安全领域,渗透测试和风险评估是两种不可或缺的技术手段。通过模拟黑客的攻击手段来发现系统中的安全漏洞,以及通过系统性的方法来识别和评估潜在的风险和威胁,两者共同为组织提供了全面的网络安全保障。随着技术的不断发展和网络环境的日益复杂,渗透测试和风险评估的重要性将日益凸显。因此,网络安全从业者应不断学习和掌握这两种技术,以应对日益严峻的网络安全挑战。
|
15天前
|
Java Spring 容器
基于注解的Aop开发,实现aop快速入门,基于注解的AOP开发
基于注解的Aop开发,实现aop快速入门,基于注解的AOP开发
|
22天前
|
机器学习/深度学习 人工智能 测试技术
探索自动化测试的前沿技术与实践
自动化测试作为提升软件开发效率和质量的关键工具,正经历着前所未有的变革。随着人工智能、机器学习、云计算等技术的融合与创新,自动化测试不断突破传统界限,展现出更智能、更高效、更灵活的发展趋势。本文将深入探讨自动化测试领域的最新技术进展,分析其在现代软件开发中的应用,并讨论如何有效整合这些技术以最大化测试效率和准确性。
|
21天前
|
人工智能 程序员 API
通义万相AIGC技术的测试体验
通义万相AIGC技术的测试体验
46 3
|
23天前
|
机器学习/深度学习 人工智能 机器人
现代软件测试中的自动化工具与技术
随着软件开发复杂性的增加,自动化测试在现代软件开发中变得至关重要。本文探讨了当前流行的自动化测试工具和技术,以及它们如何提高软件质量、加快发布速度和降低成本。
25 1
|
2天前
|
机器学习/深度学习 人工智能 运维
探索自动化测试的前沿技术与实践
随着软件行业的快速发展,传统的手动测试方法已难以满足日益增长的质量保证需求。自动化测试作为提高测试效率和准确性的关键手段,正逐渐成为软件开发过程中不可或缺的一部分。本文将深入探讨自动化测试的最新技术趋势,分析其在现代软件开发生命周期中的应用,并提供一系列实施策略,旨在帮助读者理解并掌握自动化测试的核心技术和方法。