AOP@Work: 对方面进行单元测试

发布: 2008-10-14 09:20 | 作者: 不详 | 来源: 测试时代采编 | 查看: 81次 | 进入软件测试论坛讨论

清单 2. 对 Highlighter 的集成测试

public class HighlightSearchResultsIntegrationTest extends TestCase {
Collection words;

private SearchResult result;

public void setUp() throws Exception {
    super.setUp();
    words = new ArrayList();
    words.add("big");
    words.add("grrr");

    result = new SearchResult();
    result.setTitle("I am a big bear!");
    result.setSummary("grrr growl!");
    result.setHighlightedWords(words);
}

public void testHighlighting() {
    String expected = "I am a big bear!";
    assertEquals(expected, result.getTitle());
    expected = "grrr growl!";
    assertEquals(expected, result.getSummary());
}
}

优缺点

不管是否使用 AOP，集成测试的代价和优点是类似的。不管哪种情况，主要的好处是验证代码的高层目标（换句话说，正确突出显示标题和结束语）。在进行大的重构时它会提供帮助。它还会找出当组件交互时才会出现的问题。

不过，只进行集成测试会带来一些问题。如果 HighlightSearchResultsIntegrationTest 失败，那么这可能是因为建议逻辑或者所涉及的其他类（如 SearchResult）有错误，而使方面根本没有运行。事实上，我在开发这个集成测试例子时就遇到了这种情况。我花了 20 分钟试图搞清楚为什么方面没有运行，最后发现在正则表达式中有一个暗藏的问题！

集成测试还需要更复杂的设置和断言，这使它们比分别测试单独的方面更难编写。并且很难用集成测试模拟代码需要正确处理的所有临界情况。

横切数个类的行为给集成测试带来了一个特定问题。假定对应用程序中的所有类有统一的异常处理。我们不想对每一个类测试这个新行为。相反，希望选择一个代表性的例子。但是如果选择了特定的域类（比如 Customer 类），并测试了它的错误处理方面，那么就会有模糊测试目的的可能性。测试是验证 Customer 的行为还是验证应用程序的错误处理呢？

II. 使用可视化工具

关于测试广泛分布的横切关注点的一个难题是它会报告太多的联结点。执行并检查所有的匹配是个大麻烦。（另一方面，意外加入不需要的联结点会更糟糕）。相应地，下面两个模式展现了使用在 AJDT 这样的工具中提供的人工检测横切视图补充正常测试的好处。（在撰写本文时，AspectJ 与 AJDT 结合提供了大多数可视化支持，不过，JBoss AOP 和 JBoss IDE 等其他组合同样提供了很好的可视化工具。）

模式 1. 可视化地检查横切

针对：横切规范

概述：在开发方面时使用 AJDT 的 cross-references 视图查看它要建议哪些联结点。人工验证清单是否完整，并且不包含应忽略的联结点。

例子：找出不需要的匹配

假定要突出显示标题、产品和搜索结果的汇总。不用像在清单中那样枚举每一个方法，可以说明想要找的是一个更健壮的切点。（关于健壮的切点的更多内容，请参阅参考资料中 Adrian Colyer 的 blog。）下面的切点看来是抓住了原来的想法：

public pointcut highlightedTextProperties() :
(
execution(public String get*())
&& ! execution(public * Highlightable.*(..))
);