Aaron的测试生活小说

半两五钱,笃志向前
  首页  :: 新随笔  :: 联系 :: 管理
      英文原文名叫《A Dozen Ways to Get the Testing Bug in the New Year》,是Aaron在java.net上发现的文章。原文地址http://today.java.net/pub/a/today/2004/01/22/DozenWays.html,原文是在2004年1月22日发表的,按常理说一片早已经过了时效期的文章是没有多大用处的,但是Aaron却认为时至今日该文依然值得一阅。

          测试代码之中包含了很多有用信息,因此我们可以把它看做是一种文档,它甚至可以实时反映出我们代码的运行情况。你压根不需要考虑该不该完全相信这份“文档”,你只需要亲自运行一下这些测试就可以了。如果测试失败了,输出的测试结果会告诉你什么地方的代码没有按照你所期望的样子运行。一旦我们写出了一个通过的测试方法,我们应该重视这个测试方法并把它加入到我们的版本控制系统之中。这样我们就可以在我们项目build的进程中充分利用测试的功力。

         使用JUnit可以帮助我们有效的组织我们的测试方法,而且可以应用在任何一个自己喜欢的IDE中。好了,一个新的问题出现了,我们还应该考虑到相同项目组之中可能有些人使用的IDE与自己的不一样,这个时候我们也应该保证这位同事能在他自己的机器上运行我们写的这些测试。在Java领域,很幸运我们有Ant这样可以帮助我们实现更方便的测试和Build的工具。接下来一起来看一段AntBuild.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进程中的价值。不断地向我们的版本控制系统中添加(在本地)通过了的测试方法,然后持续不断地运行所有的测试并看到这些测试全部通过,无疑这样可以增加我们对自己的代码的信心。