AspectJ和模仿对象的测试灵活性 - 编程入门网

模仿对象测试方法的支持者声称，像上面这样的方法应该被重构，以使其更加“易于模仿”。这种重构往往会产生更简洁、更灵活的设计。在一个设计良好的系统中，每个单元都通过定义良好的、支持各种实现（包括模仿实现）的接口与其上下文进行交互。

但即便在设计良好的系统中，也有测试无法轻易地影响上下文的情况出现。每当代码调用可全局访问的资源时，就会出现这种情况。举例来说，对静态方法的调用很难验证或替换，就像使用 new 操作符进行对象实例化的情况一样。

模仿对象对全局资源不起作用，因为模仿对象测试依赖于用共享通用接口的测试类手工替换域类。因为静态方法调用（和其它类型的全局资源访问）不能被覆盖，所以不能用处理实例方法的方式来“重定向”对它们的调用。

您可以向清单 4 中的方法传送 任何 Deletable ；然而，因为无法在真正类的地方装入不同的类，所以您不能使用 Java 语言的模仿方法调用替换静态方法调用。

AspectJ和模仿对象的测试灵活性(6)

一个重构示例

有些重构常常能够使应用程序代码向良好的解决方案发展，这种解决方案也可以容易地测试 ― 但事情并不总是这样。如果得出的代码更难维护或理解，为了能够测试而进行重构并没有意义。

EJB 代码可能更加难于重构为允许轻易地模仿测试的状态。举例来说，易于模仿的一种重构类型将改变下面这种代码：

//in　EJBNumber1 public　void　doSomething(){ 　　 EJBNumber2　collaborator　=　lookupEJBNumber2(); 　　 //do　something　with　collaborator }

改为这种代码：

public　void　doSomething(EJBNumber2　collaborator){ 　　 //do　something　with　collaborator }

在标准的面向对象系统中，这个重构示例允许调用者向给定单元提供合作者，从而增加了灵活性。但这种重构在基于 EJB 的系统中可能是不需要的。由于性能原因，远程 EJB 客户机需要尽可能多地避免远程方法调用。第二种方法需要客户机首先查找，然后创建 EJBNumber2 （一个与若干远程操作有关的进程）的实例。

另外，设计良好的 EJB 系统倾向于使用“分层”的方法，这时客户机层不需要了解实现细节（比如 EJBNumber2 的存在等）。获取 EJB 实例的首选方法是从 JNDI 上下文查找工厂（ Home 接口），然后调用工厂上的创建方法。这种策略给了 EJB 应用程序很多重构代码样本需要的灵活性。因为应用程序部署者可以在部署时在完全不同的 EJBNumber2 实现中交换，所以系统的行为可以轻易地进行调整。然而，JNDI 绑定不能轻易地在运行时改变。因此，模仿对象测试者面临两种选择，一是为了在 EJBNumber2 的模仿中交换而重新部署，二是放弃整个测试模型。

幸运的是，AspectJ 提供了一个折衷方法。

AspectJ 增加灵活性

AspectJ 能够在“每测试案例”的基础上提供对上下文敏感的行为修改（甚至在通常会禁止使用模仿对象的情况下）。AspectJ 的联接点模型允许名为 aspect的模块识别程序的执行点（比如从 JNDI 上下文查找对象），并定义执行这些点的代码（比如返回模仿对象，而不是继续查找）。

aspect 通过 pointcut识别程序控制流程中的点。pointcut 在程序的执行（在 AspectJ 用语中称为 joinpoint）中选取一些点，并允许 aspect 定义运行与这些 jointpoint 有关的代码。有了简单的 pointcut，我们就可以选择所有参数符合特定特征的 JNDI 查找了。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!