前言

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

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

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

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

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

2. 什么是單元測(cè)試

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

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

3. 單元測(cè)試的一般方法

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

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

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

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

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

5.1. 什么是JUnit

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

5.2. 自己編寫(xiě)測(cè)試框架的弊病

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

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

5.3. JUnit的優(yōu)勢(shì)

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