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

核心提示： 静态分析的主要作用是分析输出，并确定报告的条目是真的 bug 还是假警报，Java 理论与实践: 平衡测试，第 1 部分：不要仅编写测试，还要编写 bug 检测器(3)，编写的部分优秀分析工具或 bug 模式检测器会管理误报率；核心 FindBugs 包中的检测器已经进行了调优，目的是使误报率不

静态分析的主要作用是分析输出，并确定报告的条目是真的 bug 还是假警报。编写的部分优秀分析工具或 bug 模式检测器会管理误报率；核心 FindBugs 包中的检测器已经进行了调优，目的是使误报率不超过 50 ％，这样分析输出时不会有太多的烦麻。（将此阈值与针对 C 的 lint-like 工具进行比较，后者常常发出许多假警报，使用时相当耗时。）

将它提升一个级别

前面描述修复 bug 的方法（首先编写测试用例，然后检查修复和测试用例）反映了这样一个愿望：不仅要修复 bug，还要提高修复它的信心，并记录如何修复它，以及何时修复它。此方法比仅修复 bug 要多做许多工作，但是它给我们提供了更多的信心，我们的代码在经过多个开发人员的不断修改后可以继续使用。不过，仅为所发现的 bug 编写测试用例是一种消极方法。在代码失败之前，我们希望尽可能以最佳实践分析代码。

清单 1 通过 BigDecimal 类说明了常见的 bug。BigDecimal 是固定不变的，所以算术方法（如 add()）会返回一个新的 BigDecimal 作为其结果，而不修改调用它们的对象。清单 1 中的代码显然被假定为有条件地将运输费用添加到总体订购价格中，但是，实际上不能随意添加任何内容，因为 add() 的返回值被丢弃了：

清单 1. 典型的 bug 模式 —— 使用 mutator 方法配置 factory 方法
public　class　ShoppingCart　{　
　　private　BigDecimal　totalCost;　
　
　　private　boolean　qualifiesForFreeShipping()　{　...　}　
　　private　BigDecimal　getShippingCost()　{　...　}　
　
　　public　void　checkout()　{　
　　　　...　
　　　　if　(!qualifiesForFreeShipping())　
　　　　　　totalCost.add(getShippingCost());　//WRONG!　
　　}　
}