為了節(jié)省篇幅，上面的測試代碼省略了某些內(nèi)容，例如當(dāng)isDivisor方法的第二個(gè)參數(shù)是負(fù)數(shù)時(shí)會(huì)出現(xiàn)什么情況。
用javac *.java命令編譯這個(gè)類，然后輸入java CalculatorTest運(yùn)行它。
你應(yīng)該得到一個(gè)“不能判斷小于2的數(shù)是否素?cái)?shù)”的運(yùn)行時(shí)異常。大概形式如下，當(dāng)然顯示的行數(shù)36可能因?yàn)槟闾幚鞢alculatorTest.java中空格的方式而有所不同：
Exception in thread "main" java.lang.RuntimeException: isPrime should throw exception for numbers less than 2
at CalculatorTest.main(CalculatorTest.java:36)
換句話說，F(xiàn)actorCalculator的功能不正確。在isPrime方法前面加一個(gè)判斷可以解決這個(gè)問題，判斷參數(shù)小于2時(shí)拋出IllegalArgumentException異常。像下面的一小段代碼：
if (number < 2) {
throw new IllegalArgumentException();
}
把上面的代碼放到FactorCalculator的isPrime方法的前面。為了便于你參考，修改后的isPrime方法列在FactorCalculator.java.v2中，如果你打算直接使用這個(gè)文件，先把它改名為FactorCalculator.java。
增加了檢查后，重新編譯運(yùn)行CalculatorTest，新的CalculatorTest應(yīng)該可以通過所有測試。
三、JUnit提供測試框架的優(yōu)勢（JUnit Provides Advantages as a Test Framework）
測試Java類的內(nèi)部功能是剛才你做的那些工作了。真正的測試和剛才的簡單例子的主要區(qū)別是代碼庫的大小和復(fù)雜度。在處理一大堆代碼時(shí)，你會(huì)需要收集情況報(bào)告。但上面的例子遇到第一個(gè)錯(cuò)誤停止了，它沒有收集盡可能多的錯(cuò)誤信息，也不能報(bào)告那些測試可以通過。如果一個(gè)測試不通過，把整個(gè)測試重新編譯、運(yùn)行一遍，那開發(fā)過程肯定會(huì)非常慢。Bug經(jīng)常是相互關(guān)聯(lián)的，而且由各部分代碼交互的地方引起。一次看到多個(gè)錯(cuò)誤可以幫你分析和解決bug，對有關(guān)聯(lián)的bug的處理也會(huì)加快。
在使用JUnit重寫這個(gè)測試之前，你需要了解下述術(shù)語和測試概念：
1、單元測試（Unit test）：單元測試是指一小段代碼——絕大多數(shù)情況下都只有一個(gè)Java類——測試一個(gè)軟件或者庫非常有限的一個(gè)部分。單元測試檢驗(yàn)的代碼都很小，例如一個(gè)或幾個(gè)類。通常是測試EJB組件和普通Java類庫，不管這些類在服務(wù)器端（容器）環(huán)境中還是獨(dú)立運(yùn)行。與列表中提到的另一個(gè)概念功能測試比起來，單元測試的主要區(qū)別在于，單元測試的重點(diǎn)是終用戶一般看不到的內(nèi)部組件，而功能測試的重點(diǎn)是“點(diǎn)擊按鈕”。在JUnit中，單元測試可能是TestCase類中的一個(gè)方法，也可能是整個(gè)TestCase類。從大小上講一兩頁的代碼對單元測試應(yīng)該是合適的。如果單元測試達(dá)到十頁太夸張了，分成若干個(gè)粒度更細(xì)的測試會(huì)比較好。
2、功能測試（Functional test）：功能測試是站在終用戶的角度驗(yàn)證程序的功能是否正確。功能測試和黑盒測試是同一個(gè)意思。
3、黑盒測試（Black box test）：黑盒測試是只根據(jù)對外發(fā)布的接口或公共約定，而忽略程序內(nèi)部實(shí)現(xiàn)進(jìn)行的測試。這通常意味著你只知道應(yīng)該輸入什么，只測試預(yù)期的輸出，不知道程序如何生成這些輸出，性能、邊界影響等其它外部特征也不在你的考慮范圍內(nèi)，除非代碼的這些方面特性是公共約定的一部分。如果你開發(fā)的軟件庫中有提供給其它開發(fā)者（你的終用戶）使用的API，黑盒測試顯得尤為重要。這個(gè)重要性不僅僅是指軟件庫能按公共接口說的做，軟件庫避免公共接口中禁止或省略的內(nèi)容也很重要。如果你開發(fā)一個(gè)程序，遵守公共接口也是很重要的，因?yàn)樗鼓愫屯轮g能更有效的合作。
4、白盒測試（White box test）：白盒測試是在知道代碼如何實(shí)現(xiàn)的情況下測試一段代碼的功能。當(dāng)你要測試公共約定中沒有指定，但很重要的行為，例如性能問題時(shí)，白盒測試派上用場了。在測試某些特別復(fù)雜的算法或業(yè)務(wù)邏輯時(shí)，也需要白盒測試。這種情況下，通過白盒測試你可以把注意力集中在可能出現(xiàn)錯(cuò)誤的地方，這在黑盒測試中由于缺乏對內(nèi)部情況的了解很難做到。
5、容器內(nèi)測試（In-container test）：容器內(nèi)測試在servlet或EJB容器內(nèi)部進(jìn)行，因此能更直接的和要測試的代碼通信。Jakarta Cactus項(xiàng)目實(shí)現(xiàn)了一個(gè)免費(fèi)的測試工具Cactus，它讓你和要測試的代碼在同一個(gè)容器內(nèi)執(zhí)行，不管這個(gè)容器是servlet容器還是EJB容器。容器內(nèi)測試對黑盒功能測試沒什么用，它的作用體現(xiàn)在單元測試上。
6、測試用例（Test case）：Test case在JUnit中是一組相關(guān)的測試。Test case表現(xiàn)為繼承junit.framework.TestCase的類。Test case通常有多個(gè)方法，每個(gè)方法測試程序一方面的行為。Test case中的測試方法習(xí)慣用test作前綴命名，但并不是必須這樣做，只要不與其它方法產(chǎn)生沖突可以。
7、測試集（test suite）：Test suite是一組test case或test suites。它表現(xiàn)為繼承junit.framework.TestSuite的類。沒有任何限制要求test suite只包括test case或只包括test suite，它可以既有test case，又有test suite。一個(gè)test suite的子test suite也可以包括test case和test suite，因此允許嵌套測試。只要你愿意，你可以建立幾組test case，每一組測試程序的一個(gè)明確的小方面。一組可以形成一個(gè)test suite。然后你可以把它們綜合到一個(gè)主test suite中，后用這個(gè)主test suite測試整個(gè)程序，一個(gè)功能點(diǎn)一個(gè)功能點(diǎn)的測試。
8、測試啟動(dòng)器（Test runner）：Test runner是啟動(dòng)測試過程的JUnit類。你調(diào)用test runner，它依次執(zhí)行你預(yù)訂的測試。有幾種辦法可以定義要test runner執(zhí)行的測試。這些辦法在下面的第五部分“指定要運(yùn)行的測試”中介紹。JUnit有三種不同的test runners：text、AWT和Swing，類名分別是junit.textui.TestRunner、junit.awtui.TestRunner和junit.swingui.TestRunner。
