二、JUnit簡介及為什么要使用JUint
JUnit是對程序代碼進行單元測試的一種Java框架。通過每次修改程序之后測試代碼，程序員可以保證代碼的的少量變動不會破壞整個系統(tǒng)。要不是有Junit這樣的自動化測試工具，代碼的的反復(fù)測試簡直會把人累死而且還可能不準(zhǔn)確�，F(xiàn)在好了，測試過程可以頻繁進行而且還是自動的，所以你可以令程序錯誤降低到少。它寫的是單元測試（Unit Test）：軟件工程里的白盒測試，是測試某個類的某個方法的功能。XP 中推崇的 test first design 是基于以上的技術(shù)。
如果你要寫一段代碼：
1. 先用 junit 寫測試，然后再寫代碼
2. 寫完代碼，運行測試，測試失敗
3. 修改代碼，運行測試，直到測試成功
如果以后對程序進行修改，優(yōu)化 ( refactoring )，只要再運行測試代碼，如果所有的測試都成功，則代碼修改完成。
Java 下的 team 開發(fā)，一般采用 cvs(版本控制) + ant(項目管理) + junit(集成測試) 的模式：
1. 每天早上上班，每個開發(fā)人員從 cvs server 獲取一個整個項目的工作拷貝；
2. 拿到自己的任務(wù)，先用 junit 寫的任務(wù)的測試代碼；
3. 然后寫任務(wù)的代碼，運行測試，直到測試通過，任務(wù)完成；
4. 在下班前一兩個小時，各個開發(fā)人員把任務(wù)提交到 cvs server；
5. 然后由主管對整個項目運行自動測試，哪個測試出錯，找相關(guān)人員修改，直到所有測試通過。下班...
先寫測試，再寫代碼的好處：
從技術(shù)上強制你先考慮一個類的功能，也是這個類提供給外部的接口，而不至于太早陷入它的細節(jié)。這是面向?qū)ο筇岢囊环N設(shè)計原則。好的測試其實是一個好的文檔，這個類使用者往往可以通過查看這個類的測試代碼了解它的功能。特別的，如果你拿到別人的一個程序，對他寫測試是好的了解這個程序的功能的方法。 xp的原則是 make it simple，不是很推薦另外寫文檔，因為項目在開發(fā)過程中往往處于變動中，如果在早期寫文檔，以后代碼變動后還得同步文檔，多了一個工作，而且由于項目時間緊往往文檔寫的不全或與代碼不一致，與其這樣，不如不寫。而如果在項目結(jié)束后再寫文檔，開發(fā)人員往往已經(jīng)忘記當(dāng)時寫代碼時的種種考慮，況且有下一個項目的壓力，管理人員也不愿意再為舊的項目寫文檔，導(dǎo)致以后維護的問題。沒有人能保證需求不變動，以往項目往往對需求的變動大為頭疼，害怕這個改動會帶來其他地方的錯誤。為此，除了設(shè)計好的結(jié)構(gòu)以分割項目外（松耦合），但如果有了測試，并已經(jīng)建立了一個好的測試框架，對于需求的變動，修改完代碼后，只要重新運行測試代碼，如果測試通過，也保證了修改的成功，如果測試中出現(xiàn)錯誤，也會馬上發(fā)現(xiàn)錯在哪里，修改相應(yīng)的部分，再運行測試，直至測試完全通過。
軟件公司里往往存在開發(fā)部門和測試部門之間的矛盾：由于開發(fā)和測試分為兩個部門，多了一層溝通的成本和時間，溝通往往會產(chǎn)生錯誤的發(fā)生。而且極易形成一個怪圈：開發(fā)人員為了趕任務(wù)，寫了爛爛的代碼，把它扔給測試人員，然后寫其他的任務(wù)，測試當(dāng)然是失敗的，又把代碼拿回去重寫，而且在國內(nèi)往往一個軟件公司技術(shù)差的部門是測試部門（好的人都跑去寫代碼了），測試成了一個很頭疼的問題。這種怪圈的根源是責(zé)任不清，根據(jù) xp 中的規(guī)定：寫這個代碼的人必須為自己的代碼寫測試，而且只有測試通過，才算完成這個任務(wù)（這里的測試包括所有的測試，如果測試時發(fā)現(xiàn)由于你的程序?qū)е聞e的模塊的測試失敗，你有責(zé)任通知相關(guān)人員修改直至集成測試通過），這樣可以避免這類問題的發(fā)生。
三、安裝
1. 獲取JUnit的軟件包，從Junit(http://www.junit.org/index.htm或http://download.sourceforge.net/junit/)下載新的軟件包。這里我使用的是http://download.sourceforge.net/junit/junit2.zip。
2. 將其在適當(dāng)?shù)哪夸浵陆獍ㄎ野惭b在D:junit2）。這樣在安裝目錄（也是你所選擇的解包的目錄）下你找到一個名為junit.jar的文件。將這個jar文件加入你的CLASSPATH系統(tǒng)變量。（IDE的設(shè)置會有所不同，參看你所喜愛的IDE的配置指南）JUnit安裝完了。
四、運行
通過前面的介紹，我們對JUnit有了一個大概的輪廓。知道了它是干什么的�，F(xiàn)在讓我們動手改寫上面的測試類testCar使其符合Junit的規(guī)范－－能在JUnit中運行。
//執(zhí)行測試的類（JUnit版）
import junit.framework.*;
public class testCar extends TestCase
{
protected int expectedWheels;
protected Car myCar;
public testCar(String name)
{
super(name);
}
protected void setUp()
{
expectedWheels = 4;
myCar = new Car();
}
public static Test suite()
{
/** the type safe way */
/*
TestSuite suite= new TestSuite();
suite.addTest(
new testCar("Car.getWheels")
{
protected void runTest()
{
testGetWheels();
}
}
);
return suite;
*/
/** the dynamic way */
return new TestSuite(testCar.class);
}
public void testGetWheels()
{
assertEquals(expectedWheels， myCar.getWheels());
}
}
改版后的testCar已經(jīng)面目全非。先讓我們了解這些改動都是什么含義，再看如何執(zhí)行這個測試。
1>import語句，引入JUnit的類。（沒問題吧）
2>繼承 TestCase 。可以暫時將一個TestCase看作是對某個類進行測試的方法的集合。詳細介紹請參看JUnit資料
3>setUp()設(shè)定了進行初始化的任務(wù)。我們以后會看到setUp會有特別的用處。
4>testGetWheeels()對預(yù)期的值和myCar.getWheels()返回的值進行比較，并打印比較的結(jié)果。assertEquals是junit.framework.Assert中所定義的方法，junit.framework.TestCase繼承了junit.framework.Assert。
5>suite()是一個很特殊的靜態(tài)方法。JUnit的TestRunner會調(diào)用suite方法來確定有多少個測試可以執(zhí)行。上面的例子顯示了兩種方法：靜態(tài)的方法是構(gòu)造一個內(nèi)部類，并利用構(gòu)造函數(shù)給該測試命名(test name， 如 Car.getWheels)，其覆蓋的runTest()方法，指明了該測試需要執(zhí)行那些方法－－testGetWheels()。動態(tài)的方法是利用內(nèi)�。╮eflection）來實現(xiàn)runTest()，找出需要執(zhí)行那些測試。此時測試的名字即是測試方法（test method，如testGetWheels）的名字。JUnit會自動找出并調(diào)用該類的測試方法。
6>將TestSuite看作是包裹測試的一個容器。如果將測試比作葉子節(jié)點的話，TestSuite是分支節(jié)點。實際上TestCase，TestSuite以及TestSuite組成了一個composite Pattern。JUnit的文檔中有一篇專門講解如何使用Pattern構(gòu)造Junit框架。有興趣的朋友可以查看JUnit資料。
