Java 理论与实践: 平衡测试，第 3 部分：用方面检验设计约束

核心提示： 简单的测试方面FindBugs 这样的静态分析工具审计代码但不执行代码；面向方面的工具既提供静态类工具，也提供动态类工具，Java 理论与实践: 平衡测试，第 3 部分：用方面检验设计约束(2)，静态方面可以生成编译时警告或错误；动态方面可以把错误检测代码插入类， 在 第 1 部分 中，如果想发

简单的测试方面

FindBugs 这样的静态分析工具审计代码但不执行代码；面向方面的工具既提供静态类工具，也提供动态类工具。静态方面可以生成编译时警告或错误；动态方面可以把错误检测代码插入类。

在 第 1 部分 中，我提供了一个简单的 FindBugs 探测器，查找可能潜伏在库中的对 System.gc() 的调用。静态分析能探测的许多 bug 模式（包括这个模式）也能被方面探测到；根据具体的 bug 模式，用静态分析或用方面来做可能会更容易，所以把它们都放在工具库中，可以提高效果。

清单 1 显示了一个简单的动态方面，在要调用 System.gc() 时，抛出 AssertionError。（因为这类 bug 探测器的一个重要作用是不仅要找到您自己代码中的错误，还要找到代码依赖的库中的错误，所以可能需要告诉工具还要分析或处理这些库。）

清单 1. 执行 “不调用 System.gc()” 规则的动态方面
public　aspect　GcAspect　{　
　　pointcut　gcCalls()　:　call(void　java.lang.System.gc());　
　
　　before()　:　gcCalls()　{　
　　　　throw　new　AssertionError("Don't　call　System.gc!");　
　　}　
}　

清单 1 演示的动态方式不如使用静态分析进行测试有效，因为它要求程序在方面发现问题之前，实际地执行对 System.gc() 的调用，而不是程序只需包含一个对 System.gc() 的调用，就会被探测到。但是，很快就会看到，动态方面更灵活，因为它们能在方面触发的点上执行任意测试代码，从而对声明的问题提供更精细的控制。

也可以容易地创建一个静态方面，在编译时识别对 System.gc() 的调用，如清单 2 所示。同样，如果想发现在库代码中出现的这个 bug 模式，不仅要处理项目中的代码，还要处理它使用的库。