7. 組裝TestSuite，運行更多的test。在junit中，Test、TestCase和TestSuite三者組成了composiste pattern。通過組裝自己的TestSuite，可以完成對添加到這個TestSuite中的所有的TestCase的調用。而且這些定義的TestSuite還可以組裝成更大的TestSuite，這樣同時也方便了對于不斷增加的TestCase的管理和維護。
它的另一個好處是，可以從這個TestCase樹的任意一個節(jié)點（TestSuite或TestCase）開始調用，來完成這個節(jié)點以下的所有TestCase的調用。提高了unit test的靈活性。
8. 使用例子：
import junit.framework.Test;
import junit.framework.TestSuite;
public class TestAll{
public class TestAll{
//定義一個suite，對于junit的作用可以視為類似于java應用程序的main。
public static Test suite(){
TestSuite suite = new TestSuite("Running all tests.");
suite.addTestSuite( TestCase1.class);
suite.addTestSuite( TestCase2.class);
return suite;
}
}
運行同運行單獨的一個TestCase是一樣的，參見step 1 “運行”。
9. 使用Ant junit task。我們除了使用java來直接運行junit之外，我們還可以使用junit提供的junit task與ant結合來運行。涉及的幾個主要的ant task如下：
- <junit>，定義一個junit task
- <batchtest>，位于<junit>中，運行多個TestCase
- <test>，位于<junit>中，運行單個TestCase
- <formatter>，位于<junit>中，定義一個測試結果輸出格式
- <junitreport>，定義一個junitreport task
- <report>，位于<junitreport>中，輸出一個junit report
具體的語法請參見相關文檔。
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，不僅可以很好的指出代碼中存在的問題，而且也可以作為代碼更準確的文檔，同時還在持續(xù)集成的過程中起非常重要的作用。在此給出書寫TestCase時需要注意的幾點：
- 測試的獨立性：一次只測試一個對象，方便定位出錯的位置。這有2層意思：一個TestCase，只測試一個對象；一個TestMethod，只測試這個對象中的一個方法。
- 給測試方法一個合適的名字。
- 在assert函數(shù)中給出失敗的原因，如：assertTrue( “… should be true”， ……)，方便查錯。在這個例子中，如果無法通過assertTrue，那么給出的消息將被顯示。在junit中每個assert函數(shù)都有第一個參數(shù)是出錯時顯示消息的函數(shù)原型。
- 測試所有可能引起失敗的地方，如：一個類中頻繁改動的函數(shù)。對于那些僅僅只含有getter/setter的類，如果是由IDE（如Eclipse）產(chǎn)生的，則可不測；如果是人工寫，那么好測試一下。
- 在setUp和tearDown中的代碼不應該是與測試方法相關的，而應該是全局相關的。如針對與測試方法A和B，在setUp和tearDown中的代碼應該是A和B都需要的代碼。
- 測試代碼的組織：相同的包，不同的目錄。這樣，測試代碼可以訪問被測試類的protected變量/方法，方便測試代碼的編寫。放在不同的目錄，則方便了測試代碼的管理以及代碼的打包和發(fā)布。
