10. 使用例子：

<junit printsummary="yes" haltonfailure="no">
<classpath>
<path refid="classpath"/>
<pathelement location="${dist.junit}"/>
</classpath>
<formatter type="brief" usefile="false"/>
<formatter type="xml"/>
<batchtest todir="${doc.junitReport}">
<fileset dir="${dist.junit}" includes="**/*Test.class" />
</batchtest>
</junit>
<junitreport todir="${doc.junitReport}">
<fileset dir="${doc.junitReport}">
<include name="TEST*-*.xml"/>
</fileset>
<report format="frames" styledir="${junit.styleDir}" todir="${doc.junitReport}"/>
</junitreport> 

检查表

junit的使用并不很难，然而要书写一个好的TestCase却并非易事。一个不好的TestCase往往是既浪费了时间，也起不了实际的作用。相反，一个好的TestCase，不仅可以很好的指出代码中存在的问题，而且也可以作为代码更准确的文档，同时还在持续集成的过程中起非常重要的作用。在此给出书写TestCase时需要注意的几点：

- 测试的独立性：一次只测试一个对象，方便定位出错的位置。这有2层意思：一个TestCase，只测试一个对象；一个TestMethod，只测试这个对象中的一个方法。

- 给测试方法一个合适的名字。

- 在assert函数中给出失败的原因，如：assertTrue( “… should be true”, ……)，方便查错。在这个例子中，如果无法通过assertTrue，那么给出的消息将被显示。在junit中每个assert函数都有第一个参数是出错时显示消息的函数原型。

- 测试所有可能引起失败的地方，如：一个类中频繁改动的函数。对于那些仅仅只含有getter/setter的类，如果是由IDE（如Eclipse）产生的，则可不测；如果是人工写，那么最好测试一下。

- 在setUp和tearDown中的代码不应该是与测试方法相关的，而应该是全局相关的。如针对与测试方法A和B，在setUp和tearDown中的代码应该是A和B都需要的代码。

- 测试代码的组织：相同的包，不同的目录。这样，测试代码可以访问被测试类的protected变量/方法，方便测试代码的编写。放在不同的目录，则方便了测试代码的管理以及代码的打包和发布。一个例子如下：

src <=源代码根目录
|---com
|---mod1
|---class1
junit <=测试代码根目录
|---com
|---mod1
|---class1