Java 理论与实践: 平衡测试，第 1 部分：不要仅编写测试，还要编写 bug 检测器

核心提示： 清单 1 中的错误是一种常见的错误，它忘记了对象是不可变的，Java 理论与实践: 平衡测试，第 1 部分：不要仅编写测试，还要编写 bug 检测器(4)，从而将 factory 方法误认为 mutator 方法，如果在代码中查找此类错误，了解此问题的最好方法是编写一个包含 bug 的小程序，对

清单 1 中的错误是一种常见的错误，它忘记了对象是不可变的，从而将 factory 方法误认为 mutator 方法。如果在代码中查找此类错误，就会发现存在同一错误多次发生的情况，因为它来源于对特定库类工作方式的误解。对于查找此 bug，负责任的开发人员可能会搜索整个代码基址来查找对 BigDecimal.add()、subtract() 等方法的调用，并寻找忽略返回值的其他实例。

此策略是一个好的开头，但我们可以做得更好。在这里识别 bug 模式是非常容易的 —— 忽略不可变对象上的求值方法（value-bearing method）的结果。识别出该模式后，构建识别此模式的检测器是相对简单的一件事件。（FindBugs 在核心检测器集中有这样一个检测器。）此技术不仅可以应用于 BigDecimal，还可以应用于其他不可变类（如 BigInteger、String 或 Color）中。

花费一点时间为 bug 模式创建一个 bug 检测器，它会为您带来可观的收益。不仅可以用比手工操作更少的工作和更高的信心来审核整个项目，从中寻找 bug，而且还可以在现在和将来将同一检测器应用到其他项目中。您已针对不断恢复、随时可能出现的 bug 类型建立了防御机制，而不是在逐个实例的基础上解决 bug。

示例 bug 检测器

为说明编写 FindBugs 检测器的过程，我们编写了一个简单的检测器，它可以查找对 System.gc() 的调用。虽然调用的 System.gc() 不一定是 bug，但在实践中，它会带来更多的问题（多于它解决的问题 ）。尤其是，如果错误地调用了库中隐藏的 System.gc()，则会降低使用该库的应用程序的性能，开发人员可能会感到很茫然，对性能会如此低下感动很奇怪。

编写 bug 检测器的第一步是识别被检测的 bug 模式。在本例中，该模式非常简单，只需调用 System.gc() 即可。要编写识别字节码中此模式的检测器，则需要知道对应于 bug 模式的字节码是什么。了解此问题的最好方法是编写一个包含 bug 的小程序，对它进行编译，并使用 javap -c 解开 .class 文件。清单 2 显示了一个展示该 bug 的类：