AspectJ 和模仿对象的测试灵活性：用“test-only”行为增强单元测试

核心提示： 您可以向清单 4 中的方法传送 任何 Deletable ；然而，因为无法在真正类的地方装入不同的类，AspectJ 和模仿对象的测试灵活性：用“test-only”行为增强单元测试(9)，所以您不能使用 Java 语言的模仿方法调用替换静态方法调用， 一个重构示例有些重构常常能够使应用程序代码

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

一个重构示例

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

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 的模仿中交换而重新部署，二是放弃整个测试模型。