单元测试和静态分析通常被看作是有助于确保程序的正确性的互不相干的方法。本文研究了这两种方法之间的关系，并讨论了构成每种方法工作构架的工具如何相得益彰。特别地，Eric Allen 讨论了一些可用而又令人兴奋的新应用程序，这些应用程序允许您进一步提升您的单元测试。
这是一场古老的争论 — 哪种方法对产生健壮代码更有价值：测试还是静态分析和验证？您会在程序员的日常工作中听到这种争论，尤其是在极端编程（Extreme Programming）论坛上。（请参阅我们由 Roy Miller 主持的XP 论坛。）
支持静态分析（包括类型检查）的主要论据是：其结果适用程序所有可能的运行，而通过单元测试只能保证被测试的组件（在测试它们的平台上）只适用测试组件的特定输入。
支持单元测试的主要论据是它更容易处理。您可以测试程序的许多约束，这些约束远远超出了同期的静态分析工具所能达到的范围。
请允许我在此冒昧地说一句：我认为将这两种工具看作对立的是一个错误。每种工具都有助于构建更健壮的程序。实际上，它们可以通过非常强大的方式进行互补。
每种工具都有各自的长处，对于补充另一种工具特别有用：
单元测试能显示执行的常用路径，从而显示程序是如何运行的。 分析工具能检查单元测试提供的覆盖范围。让我们研究这其中的每个属性，并讨论一些可帮助您将其长处带给其它方法的工具。
显示常用执行路径的单元测试
单元测试套件提供了程序组件的示例用法的稳固基础。通过检查测试运行时程序是如何运作的，分析工具可以就开发人员希望在程序中保持的不变量进行试探性推测（就和程序员阅读单元测试所做的一样）。
还有另一种方法，其中单元测试可以是一种可执行的文档形式。在从单元测试的运行中从特殊到一般地推断出推测性不变量之后，分析工具可以尝试从一般到特殊地验证不变量的存在，或者它可以利用可在运行时检查的断言注释该代码。
在任何一种情况下，在该工具做任何其它工作之前，最好向用户返回推测的不变量集的报告，以询问用户真正想要哪些不变量。顺便提一下，如果此类工具向用户报告了许多他们不想要的不变量，这可能是单元测试出了问题的信号 — 例如，它们不够一般。
可用这种方式与单元测试一起使用的工具是 Daikon，它是一款来自 MIT 的 Mike Ernst 的程序分析小组的免费的、试验性的工具。Daikon 分析程序的运行（例如单元测试的运行），并尝试推测不变量。然后它询问用户是否想要这些不变量，并将用户想要的不变量作为断言插入程序。
例如，假定我们编写一个向量（Vector）的适配器，该适配器实现接口Sequence，该接口包含用于检索元素的方法lookup和用于将元素放在向量末尾的方法insert。方法lookup带有一个索引i，用来访问它所包含的向量。
假定该数组的长度存储在字段length中。通过维护适配器中的长度，我们可以不通知向量本身就将元素从其尾部删除。
让我们为这个假想的简单适配器编写一个简单的测试用例：
清单 1. 向量容器中简单查找方法的测试用例
import junit.framework.TestCase;public class VectorAdapterTest extends TestCase {
public VectorAdapterTest(String name) {
super(name);
}
文章来源于领测软件测试网 https://www.ltesting.net/
