单元测试和静态分析通常被看作是有助于确保程序的正确性的互不相干的方法。本文研究了这两种方法之间的关系,并讨论了构成每种方法工作构架的工具如何相得益彰。特别地,Eric Allen 讨论了一些可用而又令人兴奋的新应用程序,这些应用程序允许您进一步提升您的单元测试。 这是一场古老的争论 — 哪种方法对产生健壮代码更有价值:测试还是静态分析和验证?您会在程序员的日常工作中听到这种争论,尤其是在极端编程(Extreme Programming)CC%B3');" target="_self">论坛上。(请参阅我们由 Roy Miller 主持的 XP 论坛。) 支持静态分析(包括类型检查)的主要论据是:其结果适用程序所有可能的运行,而通过单元测试只能保证被测试的组件(在测试它们的平台上)只适用测试组件的特定输入。 支持单元测试的主要论据是它更容易处理。您可以测试程序的许多约束,这些约束远远超出了同期的静态分析工具所能达到的范围。 请允许我在此冒昧地说一句:我认为将这两种工具看作对立的是一个错误。每种工具都有助于构建更健壮的程序。实际上,它们可以通过非常强大的方式进行互补。 每种工具都有各自的长处,对于补充另一种工具特别有用:
让我们研究这其中的每个属性,并讨论一些可帮助您将其长处带给其它方法的工具。 显示常用执行路径的单元测试 还有另一种方法,其中单元测试可以是一种可执行的文档形式。在从单元测试的运行中从特殊到一般地推断出推测性不变量之后,分析工具可以尝试从一般到特殊地验证不变量的存在,或者它可以利用可在运行时检查的断言注释该代码。 在任何一种情况下,在该工具做任何其它工作之前,最好向用户返回推测的不变量集的报告,以询问用户真正想要哪些不变量。顺便提一下,如果此类工具向用户报告了许多他们不想要的不变量,这可能是单元测试出了问题的信号 — 例如,它们不够一般。 可用这种方式与单元测试一起使用的工具是 Daikon,它是一款来自 MIT 的 Mike Ernst 的程序分析小组的免费的、试验性的工具。Daikon 分析程序的运行(例如单元测试的运行),并尝试推测不变量。然后它询问用户是否想要这些不变量,并将用户想要的不变量作为断言插入程序。 例如,假定我们编写一个向量(Vector)的适配器,该适配器实现接口 假定该数组的长度存储在字段 | |
clearcase/" target="_blank" >cccccc height=17>import junit.framework.TestCase;
public class VectorAdapterTest extends TestCase { | |
然后我们可以实现我们的适配器以通过这个测试,如下所示: | |
import java.util.Vector;
public class VectorAdapter implements Sequence { interface Sequence { | |
当 Daikon 在这段代码上运行时,它可能推断:对于方法 然后程序员可以检查 Daikon 报告的不变量,从而更好地了解其测试覆盖程序的范围到底怎么样。例如,如果 Daikon 开始推断出大量不想要的不变量,这意味着单元测试只是用不具代表性的可能的程序输入的子集检测了程序。 尽管 Daikon 是用 Java 语言编写的,但它需要用 C++ 编写的前端,这削弱了它原有的可移植性。尽管如此,还是可以在线获得针对许多主要平台的前端构建。此外,Daikon 团队也打算添加其它平台所需要的构建。 (您可以在参考资料一节找到关于 Daikon 的下载信息和更多内容。) 可以检查单元测试覆盖范围的分析工具
目前有几种试图自动从代码产生单元测试的免费工具,但大多数担任这项任务的免费工具还处于起步阶段。其中一些比较有希望的是 JUnitDoclet 和 JUB(“JUnit test case Builder”的缩写),可在 SourceForge 上得到它们(参考资料一节提供了它们的链接)。 关于这些类型的工具,要牢记的要点是:最适宜应用于通过测试更新旧代码。当构建新项目时,它们的作用不大。 为什么会这样呢?因为新项目应该与项目上的单元测试是一前一后构建的。开发单元测试是构建设计的强有力的方法;针对组件的 API 就是在编写测试时隐式地为它们设计的。此外,以这种风格进行设计向设计师提供了即时的反馈。糟糕的设计将非常难于编写测试!并且,任何分析工具在确定为程序编写什么测试这方面,都很难做得象设计师那样好。 第二种分析工具分析程序及其单元测试,并确定测试能在多大范围内覆盖程序。与刚才提到的第一类工具不同,此类工具对每个项目都是有用的。实际上,极端编程团队可以考虑将此类工具集成到他们的代码提交过程中。那么,他们不仅能够防止代码在通过所有测试之前被提交,而且可以防止代码在未经测试的情况下提交!不仅懒惰会导致测试覆盖范围偏小,错误也可能导致同样后果,因此,此类强制措施对任何技能(和完整性)级别的程序员都有用。 Clover 是一种可以执行此类分析的新的并且特别有希望的工具。Clover 是 Ant 的插件,Ant 是 Clover 分两阶段过程进行工作。首先,它在编译时检测代码。然后,在测试时将有关测试的运行信息写到用来生成报告的数据库中(通过 GUI、网页或在控制台中)。 将 Clover 集成到使用 Ant 的现有项目中很简单。这涉及调整项目的 build.xml 文件以添加几个在编译、记录测试和生成报表期间检测代码的目标。例如,假定我们有一个带构建和编译目标的 build.xml 文件。我们所必须做的全部工作是将 Clover JAR 文件放到我们的 Ant 库目录中,并如下所示扩展 build.xml 文件(Clover 用户指南中提供了这些和类似于 Ant 目标的信息;为了方便,我在这里包括了它们): | |
<property name="clover.initstring" value="/tmp/mycoverage.db"/>
<target name="with.clover"> <path id="clover.classpath"> <target name="clover.report"> | |
特性 在上面的代码中,我们将生成 HTML 报告。我们也可以生成文本报告(对于提供给脚本以确定测试的覆盖范围是否可接受非常有用)和基于 Swing 的报告。 设置 | |
$ ant with.clover compile test $ ant clover.report | |
就是这么简单。请查阅流行的编码工具 JBoss 和 Ant 的在线 Clover 报告,以获取一些样本输出。(您可以在参考资料一节找到更多有关这些内容的下载信息和其它信息。) 两种方法的结合 将来,其它工具可能会提供更强有力的单元测试能力。例如,类型推断(type-inference)引擎和优化编译器可以从现有的单元测试推断线索、UML 生成工具可以从测试构造各种图表(不仅是类图)等等。对于合并这些方法以获得更佳的代码构建和故障诊断而言,还存在着巨大的空间可以进行创造性开发和实验。 请记住每种方法的属性及其长处:
每种方法的长处都可以用来弥补另一种方法的潜在弱点。 下一次,我们将研究增强的单元测试的另一条路径,并了解一些最新的工具,它们可用于帮助您在 GUI 上开发单元测试。
|