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

核心提示： 在执行时，该测试将验证 Deleter 成功地调用集合中每个对象上的 delete() ，AspectJ 和模仿对象的测试灵活性：用“test-only”行为增强单元测试(8)，模仿对象测试按这种方式精确地控制被测试类的环境，并验证单元与它们正确地交互，因为模仿对象测试依赖于用共享通用接口的测试

在执行时，该测试将验证 Deleter 成功地调用集合中每个对象上的 delete() 。模仿对象测试按这种方式精确地控制被测试类的环境，并验证单元与它们正确地交互。

模仿对象的局限性

面向对象的编程限制了模仿对象测试对被测试类的执行的影响。举例来说，如果我们在测试一个稍微不同的 delete() 方法 ― 也许是在删除一些可删除对象之前查找这些对象的列表的方法 ― 测试就不会这么容易地提供模仿对象了。下面的方法使用模仿对象可能很难测试：

清单 7. 一个很难模仿的方法

public　static　void　deleteAllObjectMatching(String　criteria){　
　　　　　　Collection　deletables　=　fetchThemFromSomewhere(criteria);　
　　　　　　for(Iterator　it　=　deletables.iterator();　it.hasNext();){　
　　　　　　　　((Deletable)it.next()).delete();　
　　　　　　}　
　　　　}　

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

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

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