译释Dozen ways to find bugs(9)——Make it part of your build process
Posted on 2009-03-02 21:25 Aaron Wu 阅读(170) 评论(0) 编辑 收藏 举报使用JUnit可以帮助我们有效的组织我们的测试方法,而且可以应用在任何一个自己喜欢的IDE中。好了,一个新的问题出现了,我们还应该考虑到相同项目组之中可能有些人使用的IDE与自己的不一样,这个时候我们也应该保证这位同事能在他自己的机器上运行我们写的这些测试。在Java领域,很幸运我们有Ant这样可以帮助我们实现更方便的测试和Build的工具。接下来一起来看一段Ant的Build.XML,它的功能旨在运行所有以符合*Test命名规则的测试方法:
<path id="build.classpath">
<pathelement location="${classes.dir}" />
<pathelement location="${lib.dir}/junit.jar" />
</path>
<target name="test" depends="compile" description="Runs all the *Test tests">
<junit haltonfailure="true" printsummary="true">
<batchtest>
<fileset dir="${classes.dir}" includes="**/*Test.class" />
</batchtest>
<formatter type="brief" usefile="false" />
<classpath refid="build.classpath" />
</junit>
</target>
首先我们注意到<Path>节点的使用,它显式地为Build声明了一个ClassPath而不是依赖于CLASSPATH环境变量是否被正确地设置,这样就解决了不同机器上classpath设置可能导致的问题。其次,我们又注意到Test任务依赖于Complie任务,这就表示Test任务和Complie任务会连续(先Complie后紧接着Test)运行,而项目组中的人员只需要从版本控制系统中签出项目并输入:
ant test
最后,我们再看一看<Junit>任务中有一个配置haltonfailure被设置成了true,这表示如果测试失败,build进程也会被标志为失败,毕竟当有测试失败的时候,build的代码中一定是由问题存在的。
关于这个片段我们就只介绍到这里了。现在我们已经有了一个编译源代码并运行测试的任务了,这个时候我们需要考虑的是怎样让Test任务在指定的时间自动运行起来。这里有很多种方法,例如我们可以使用CruiseControl或者 Anthill(都是免费的),借助于他们我们可使用任何一台空闲的机器上任意次地运行我们的Ant任务。使用一个单独Build-Test的机器意味着我们所build和测试的项目处于版本控制之中。(如果有过使用版本控制的经验,你就会知道使用一台独立的机器来进行版本控制是很必要的,它可以帮助我们发现很多问题。)如果build失败的话,Build-Test的控制者(即CruiseControl之类的工具)还会给相关人员发送邮件以促使导致build失败的问题被尽快解决。
好了,最后还要重复的就是:无论我们拥有了多大数量的测试方法(代码),我们都应该认识到将测试集成到我们的build进程中的价值。不断地向我们的版本控制系统中添加(在本地)通过了的测试方法,然后持续不断地运行所有的测试并看到这些测试全部通过,无疑这样可以增加我们对自己的代码的信心。