前言

考察目前關(guān)于單元測試和JUnit的文章，要么是介紹單元測試的理論，要么是通過一個簡單的HelloWorld例子介紹工具的使用。這樣很容易使讀者在實(shí)際應(yīng)用中無從下手。因?yàn)橹挥泄ぞ叨鴽]有理論的指導(dǎo)，將嚴(yán)重消弱了工具的作用，終只能是沙灘建樓，達(dá)不到預(yù)期的目標(biāo)；只有理論而沒有工具的支持，也使得理論難有很好的著力點(diǎn)，終使理論流于空泛。本文試圖通過先講解單元測試?yán)碚�，進(jìn)而將這些理論結(jié)合到JUnit的使用當(dāng)中，后通過對一個實(shí)用的、可以重用的時(shí)間操作類采用JUnit進(jìn)行單元測試來完整闡述單元測試的思想、方法、以及工具的使用。作者相信，只有通過這樣，才能讓讀者真正把單元測試做好。

1. 為什么要進(jìn)行單元測試

    一個特定的開發(fā)組織或軟件應(yīng)用系統(tǒng)的測試水平取決于對那些未發(fā)現(xiàn)的Bug的潛在后果的重視程度。這種后果一方面常常會被軟件的開發(fā)人員所忽視，而另一方面卻有可能損害組織的信譽(yù)，并且會導(dǎo)致對未來的市場產(chǎn)生負(fù)面的影響。相反地，一個可靠的軟件系統(tǒng)的良好的聲譽(yù)將有助于一個開發(fā)組織獲取未來的市場。

    很多研究成果表明，無論什么時(shí)候作出修改都要進(jìn)行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進(jìn)行測試將使效率和質(zhì)量得到好的保證。Bug發(fā)現(xiàn)得越晚，修改它所需的費(fèi)用越高，因此從經(jīng)濟(jì)角度來看，應(yīng)該盡可能早的查找和修改Bug。在修改費(fèi)用變得過高之前，單元測試是一個在早期抓住Bug的機(jī)會。

    相比后階段的測試，單元測試的創(chuàng)建更簡單、維護(hù)更容易，并且可以更方便的進(jìn)行重復(fù)。 從全程的費(fèi)用來考慮，相比起那些復(fù)雜且曠日持久的集成測試，或是不穩(wěn)定的軟件系統(tǒng)來說， 單元測試所需的費(fèi)用是很低的。研究顯示高達(dá)50%的維護(hù)工作量被花在那些總是會有的Bug的修改上面。如果這些Bug在開發(fā)階段被排除掉的話，那么工作量可以節(jié)省下來。當(dāng)考慮到軟件維護(hù)費(fèi)用可能會比初的開發(fā)費(fèi)用高出數(shù)倍的時(shí)候，這種潛在的對50%軟件維護(hù)費(fèi)用的節(jié)省將對整個軟件生命周期費(fèi)用產(chǎn)生重大的影響。

2. 什么是單元測試

    單元測試是對小的可測試軟件元素（單元）實(shí)施的測試，它所測試的內(nèi)容包括內(nèi)部結(jié)構(gòu)（如邏輯和數(shù)據(jù)流）以及單元的功能和可觀測的行為。這里的單元不一定是指一個具體的函數(shù)或一個類的方法，“單元”是：
（1）可測試的、小的、不可再分的程序模塊。
（2）有明確的功能、規(guī)格定義。
（3）有明確的接口定義，清晰地與同一程序的其他單元劃分開來。

    在具體實(shí)現(xiàn)時(shí)，單元測試也可能對應(yīng)的是多個程序文件中的一組函數(shù)。在一種傳統(tǒng)的結(jié)構(gòu)化編程語言中，比如C，要進(jìn)行測試的單元一般是函數(shù)或子過程。在象C++這樣的面向?qū)ο蟮恼Z言中，要進(jìn)行測試的基本單元是類。單元測試的原則同樣被擴(kuò)展到第四代語言(4GL)的開發(fā)中，在這里基本單元被典型地劃分為一個菜單或顯示界面。

3. 單元測試的一般方法

    單元測試的方法一般分為兩類：白盒方法和黑盒方法。白盒方法通常是分析單元內(nèi)部結(jié)構(gòu)后通過對單元輸入輸出的用例構(gòu)造，達(dá)到單元內(nèi)程序路徑的大覆蓋，盡量保證單元內(nèi)部程序運(yùn)行路徑處理正確，它側(cè)重于單元內(nèi)部結(jié)構(gòu)的測試，依賴于對單元實(shí)施情況的了解。

    黑盒方法通過對單元輸入輸出的用例構(gòu)造驗(yàn)證單元的特性和行為，側(cè)重于核實(shí)單元的可觀測行為和功能，并不依賴于對單元實(shí)施情況的了解。進(jìn)行單元測試必須綜合使用上述兩個方法，否則，單元測試很可能是不成功、不完整和不徹底的。

4. 單元測試的目標(biāo)

    單元測試要達(dá)到的目標(biāo)，總體來說是保證單元內(nèi)部的處理是正確的、沒有遺漏和多余功能。細(xì)分而言，單元測試要達(dá)到以下幾個目標(biāo)：
（1）信息能否正確地流入和流出單元。
（2）在單元工作過程中，其內(nèi)部數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯誤，也包括全局變量在單元中的處理和影響。
（3）在為限制數(shù)據(jù)加工而設(shè)置的邊界處，能否正確工作。
（4）單元的運(yùn)行能否做到滿足特定的邏輯覆蓋。
（5）單元中發(fā)生了錯誤，其中的出錯處理措施是否有效。

5. 為什么要使用JUnit進(jìn)行單元測試

5.1. 什么是JUnit

    JUnit是對程序代碼進(jìn)行單元測試的一種Java框架。通過每次修改程序之后測試代碼，程序員可以保證代碼的的少量變動不會破壞整個系統(tǒng)。官方對JUnit的定義是“JUnit is a simple framework to write repeatable tests.”。

5.2. 自己編寫測試框架的弊病

    自己編寫測試框架進(jìn)行單元測試一般有兩個方法。第一種方法是在要測試的類的main()方法中編寫測試代碼。隨著程序越變越大，這種開發(fā)方法很快開始顯現(xiàn)出了缺陷：

（1）混亂。類接口越大，main() 越大。類可能僅僅因?yàn)檎�常的測試變得非常龐大。
（2）代碼膨脹。由于加入了測試，所以產(chǎn)品代碼比所需要的要大。
（3）測試不可靠。main() 是代碼的一部分，main() 對其他開發(fā)者通過類接口無法訪問的私有成員和方法享有訪問權(quán)。出于這個原因，這種測試方法很容易出錯。
（4）很難自動測試。要進(jìn)行自動測試，必須創(chuàng)建另一程序來將參數(shù)傳遞給 main()。第二種方法是編寫一個測試類框架，它雖然能夠克服上個方法的缺陷，但增加了開發(fā)組織維護(hù)這個測試類框架的工作量，為立即大規(guī)模的重用設(shè)置障礙。而且，由于這個測試框架是內(nèi)部開發(fā)的，存在著與業(yè)界難于交流和溝通的弊病。

5.3. JUnit的優(yōu)勢

（1）需要編寫自己的框架。
（2）它是開放源代碼，因此不需要購買框架。
（3）開放源代碼社區(qū)中的其他開發(fā)者會使用它，因此可以找到許多示例。
（4）可以將測試代碼與產(chǎn)品代碼分開。
（5）易于集成到構(gòu)建過程中。