(二)单元测试利器 JUnit 4
JUnit 深入
??????? 當(dāng)然,JUnit 提供的功能決不僅僅如此簡單,在接下來的內(nèi)容中,我們會(huì)看到 JUnit 中很多有用的特性,掌握它們對(duì)您靈活的編寫單元測試代碼非常有幫助。
Fixture
??????? 何謂 Fixture?它是指在執(zhí)行一個(gè)或者多個(gè)測試方法時(shí)需要的一系列公共資源或者數(shù)據(jù),例如測試環(huán)境,測試數(shù)據(jù)等等。在編寫單元測試的過程中,您會(huì)發(fā)現(xiàn)在大部分的測試方法在進(jìn)行真正的測試之前都需要做大量的鋪墊——為設(shè)計(jì)準(zhǔn)備 Fixture 而忙碌。這些鋪墊過程占據(jù)的代碼往往比真正測試的代碼多得多,而且這個(gè)比率隨著測試的復(fù)雜程度的增加而遞增。當(dāng)多個(gè)測試方法都需要做同樣的鋪墊時(shí),重復(fù)代碼的“壞味道”便在測試代碼中彌漫開來。這股“壞味道”會(huì)弄臟您的代碼,還會(huì)因?yàn)槭韬鲈斐慑e(cuò)誤,應(yīng)該使用一些手段來根除它。
??????? JUnit 專門提供了設(shè)置公共 Fixture 的方法,同一測試類中的所有測試方法都可以共用它來初始化 Fixture 和注銷 Fixture。和編寫 JUnit 測試方法一樣,公共 Fixture 的設(shè)置也很簡單,您只需要:
1.?使用注解 org,junit.Before 修飾用于初始化 Fixture 的方法。
2.?使用注解 org.junit.After 修飾用于注銷 Fixture 的方法。
3.?保證這兩種方法都使用 public void 修飾,而且不能帶有任何參數(shù)。
??????? 遵循上面的三條原則,編寫出的代碼大體是這個(gè)樣子:
//初始化Fixture方法
@Before public void init(){……}
//注銷Fixture方法
@After public void destroy(){……}
??????? 這樣,在每一個(gè)測試方法執(zhí)行之前,JUnit 會(huì)保證 init 方法已經(jīng)提前初始化測試環(huán)境,而當(dāng)此測試方法執(zhí)行完畢之后,JUnit 又會(huì)調(diào)用 destroy 方法注銷測試環(huán)境。注意是每一個(gè)測試方法的執(zhí)行都會(huì)觸發(fā)對(duì)公共 Fixture 的設(shè)置,也就是說使用注解 Before 或者 After 修飾的公共 Fixture 設(shè)置方法是方法級(jí)別的(圖5)。這樣便可以保證各個(gè)獨(dú)立的測試之間互不干擾,以免其它測試代碼修改測試環(huán)境或者測試數(shù)據(jù)影響到其它測試代碼的準(zhǔn)確性。
圖5 方法級(jí)別 Fixture 執(zhí)行示意圖
???????????????????????????????????????????
??????? 可是,這種 Fixture 設(shè)置方式還是引來了批評(píng),因?yàn)樗实拖?#xff0c;特別是在設(shè)置 Fixture 非常耗時(shí)的情況下(例如設(shè)置數(shù)據(jù)庫鏈接)。而且對(duì)于不會(huì)發(fā)生變化的測試環(huán)境或者測試數(shù)據(jù)來說,是不會(huì)影響到測試方法的執(zhí)行結(jié)果的,也就沒有必要針對(duì)每一個(gè)測試方法重新設(shè)置一次 Fixture。因此在 JUnit 4 中引入了類級(jí)別的 Fixture 設(shè)置方法,編寫規(guī)范如下:
1.?使用注解 org,junit.BeforeClass 修飾用于初始化 Fixture 的方法。
2.?使用注解 org.junit.AfterClass 修飾用于注銷 Fixture 的方法。
3.?保證這兩種方法都使用 public static void 修飾,而且不能帶有任何參數(shù)。
??????? 類級(jí)別的 Fixture 僅會(huì)在測試類中所有測試方法執(zhí)行之前執(zhí)行初始化,并在全部測試方法測試完畢之后執(zhí)行注銷方法(圖6)。代碼范本如下:
//類級(jí)別Fixture初始化方法
@BeforeClass public static void dbInit(){……}
?
//類級(jí)別Fixture注銷方法
?@AfterClass public static void dbClose(){……}
圖6 類級(jí)別 Fixture 執(zhí)行示意圖
????????????????
異常以及時(shí)間測試
??????? 注解 org.junit.Test 中有兩個(gè)非常有用的參數(shù):expected 和 timeout。參數(shù) expected 代表測試方法期望拋出指定的異常,如果運(yùn)行測試并沒有拋出這個(gè)異常,則 JUnit 會(huì)認(rèn)為這個(gè)測試沒有通過。這為驗(yàn)證被測試方法在錯(cuò)誤的情況下是否會(huì)拋出預(yù)定的異常提供了便利。舉例來說,方法 supportDBChecker 用于檢查用戶使用的數(shù)據(jù)庫版本是否在系統(tǒng)的支持的范圍之內(nèi),如果用戶使用了不被支持的數(shù)據(jù)庫版本,則會(huì)拋出運(yùn)行時(shí)異常 UnsupportedDBVersionException。測試方法 supportDBChecker 在數(shù)據(jù)庫版本不支持時(shí)是否會(huì)拋出指定異常的單元測試方法大體如下:
@Test(expected=UnsupportedDBVersionException.class)
?public void unsupportedDBCheck(){
??……
}
??????? 注解 org.junit.Test 的另一個(gè)參數(shù) timeout,指定被測試方法被允許運(yùn)行的最長時(shí)間應(yīng)該是多少,如果測試方法運(yùn)行時(shí)間超過了指定的毫秒數(shù),則JUnit認(rèn)為測試失敗。這個(gè)參數(shù)對(duì)于性能測試有一定的幫助。例如,如果解析一份自定義的 XML 文檔花費(fèi)了多于 1 秒的時(shí)間,就需要重新考慮 XML 結(jié)構(gòu)的設(shè)計(jì),那單元測試方法可以這樣來寫:
@Test(timeout=1000)
?public void selfXMLReader(){
??……
}
忽略測試方法
??????? JUnit 提供注解 org.junit.Ignore 用于暫時(shí)忽略某個(gè)測試方法,因?yàn)橛袝r(shí)候由于測試環(huán)境受限,并不能保證每一個(gè)測試方法都能正確運(yùn)行。例如下面的代碼便表示由于沒有了數(shù)據(jù)庫鏈接,提示 JUnit 忽略測試方法 unsupportedDBCheck:
@ Ignore(“db is down”)
@Test(expected=UnsupportedDBVersionException.class)
?public void unsupportedDBCheck(){
??……
}
??????? 但是一定要小心。注解 org.junit.Ignore 只能用于暫時(shí)的忽略測試,如果需要永遠(yuǎn)忽略這些測試,一定要確認(rèn)被測試代碼不再需要這些測試方法,以免忽略必要的測試點(diǎn)。
測試運(yùn)行器
??????? 又一個(gè)新概念出現(xiàn)了——測試運(yùn)行器,JUnit 中所有的測試方法都是由它負(fù)責(zé)執(zhí)行的。JUnit 為單元測試提供了默認(rèn)的測試運(yùn)行器,但 JUnit 并沒有限制您必須使用默認(rèn)的運(yùn)行器。相反,您不僅可以定制自己的運(yùn)行器(所有的運(yùn)行器都繼承自 org.junit.runner.Runner),而且還可以為每一個(gè)測試類指定使用某個(gè)具體的運(yùn)行器。指定方法也很簡單,使用注解 org.junit.runner.RunWith 在測試類上顯式的聲明要使用的運(yùn)行器即可:
@RunWith(CustomTestRunner.class)
public class TestWordDealUtil {
……
}
??????? 顯而易見,如果測試類沒有顯式的聲明使用哪一個(gè)測試運(yùn)行器,JUnit 會(huì)啟動(dòng)默認(rèn)的測試運(yùn)行器執(zhí)行測試類(比如上面提及的單元測試代碼)。一般情況下,默認(rèn)測試運(yùn)行器可以應(yīng)對(duì)絕大多數(shù)的單元測試要求;當(dāng)使用 JUnit 提供的一些高級(jí)特性(例如即將介紹的兩個(gè)特性)或者針對(duì)特殊需求定制 JUnit 測試方式時(shí),顯式的聲明測試運(yùn)行器就必不可少了。
測試套件
??????? 在實(shí)際項(xiàng)目中,隨著項(xiàng)目進(jìn)度的開展,單元測試類會(huì)越來越多,可是直到現(xiàn)在我們還只會(huì)一個(gè)一個(gè)的單獨(dú)運(yùn)行測試類,這在實(shí)際項(xiàng)目實(shí)踐中肯定是不可行的。為了解決這個(gè)問題,JUnit 提供了一種批量運(yùn)行測試類的方法,叫做測試套件。這樣,每次需要驗(yàn)證系統(tǒng)功能正確性時(shí),只執(zhí)行一個(gè)或幾個(gè)測試套件便可以了。測試套件的寫法非常簡單,您只需要遵循以下規(guī)則:
1.?創(chuàng)建一個(gè)空類作為測試套件的入口。
2.?使用注解 org.junit.runner.RunWith 和 org.junit.runners.Suite.SuiteClasses 修飾這個(gè)空類。
3.?將 org.junit.runners.Suite 作為參數(shù)傳入注解 RunWith,以提示 JUnit 為此類使用套件運(yùn)行器執(zhí)行。
4.?將需要放入此測試套件的測試類組成數(shù)組作為注解 SuiteClasses 的參數(shù)。
5.?保證這個(gè)空類使用 public 修飾,而且存在公開的不帶有任何參數(shù)的構(gòu)造函數(shù)。
package com.ai92.cooljunit;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
……
/**
?* 批量測試 工具包 中測試類
?* @author Ai92
?*/
@RunWith(Suite.class)
@Suite.SuiteClasses({TestWordDealUtil.class})
public class RunAllUtilTestsSuite {
}
??????? 上例代碼中,我們將前文提到的測試類 TestWordDealUtil 放入了測試套件 RunAllUtilTestsSuite 中,在 Eclipse 中運(yùn)行測試套件,可以看到測試類 TestWordDealUtil 被調(diào)用執(zhí)行了。測試套件中不僅可以包含基本的測試類,而且可以包含其它的測試套件,這樣可以很方便的分層管理不同模塊的單元測試代碼。但是,您一定要保證測試套件之間沒有循環(huán)包含關(guān)系,否則無盡的循環(huán)就會(huì)出現(xiàn)在您的面前……。
參數(shù)化測試
??????? 回顧一下我們?cè)谛」?jié)“JUnit 初體驗(yàn)”中舉的實(shí)例。為了保證單元測試的嚴(yán)謹(jǐn)性,我們模擬了不同類型的字符串來測試方法的處理能力,為此我們編寫大量的單元測試方法。可是這些測試方法都是大同小異:代碼結(jié)構(gòu)都是相同的,不同的僅僅是測試數(shù)據(jù)和期望值。有沒有更好的方法將測試方法中相同的代碼結(jié)構(gòu)提取出來,提高代碼的重用度,減少復(fù)制粘貼代碼的煩惱?在以前的 JUnit 版本上,并沒有好的解決方法,而現(xiàn)在您可以使用 JUnit 提供的參數(shù)化測試方式應(yīng)對(duì)這個(gè)問題。
參數(shù)化測試的編寫稍微有點(diǎn)麻煩(當(dāng)然這是相對(duì)于 JUnit 中其它特性而言):
1.?為準(zhǔn)備使用參數(shù)化測試的測試類指定特殊的運(yùn)行器 org.junit.runners.Parameterized。
2.?為測試類聲明幾個(gè)變量,分別用于存放期望值和測試所用數(shù)據(jù)。
3.?為測試類聲明一個(gè)使用注解 org.junit.runners.Parameterized.Parameters 修飾的,返回值為 java.util.Collection 的公共靜態(tài)方法,并在此方法中初始化所有需要測試的參數(shù)對(duì)。
4.?為測試類聲明一個(gè)帶有參數(shù)的公共構(gòu)造函數(shù),并在其中為第二個(gè)環(huán)節(jié)中聲明的幾個(gè)變量賦值。
5.?編寫測試方法,使用定義的變量作為參數(shù)進(jìn)行測試。
我們按照這個(gè)標(biāo)準(zhǔn),重新改造一番我們的單元測試代碼:
package com.ai92.cooljunit;
import static org.junit.Assert.assertEquals;
import java.util.Arrays;
import java.util.Collection;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
@RunWith(Parameterized.class)
public class TestWordDealUtilWithParam {
??private String expected;
?
??private String target;
?
??@Parameters
??public static Collection words(){
???? ??return Arrays.asList(new Object[][]{
?????????? ?{"employee_info", "employeeInfo"},??//測試一般的處理情況
?????????? ?{null, null},???????//測試 null 時(shí)的處理情況
?????????? ?{"", ""},????????//測試空字符串時(shí)的處理情況
?????????? ?{"employee_info", "EmployeeInfo"},??//測試當(dāng)首字母大寫時(shí)的情況
?????????? ?{"employee_info_a", "employeeInfoA"},?//測試當(dāng)尾字母為大寫時(shí)的情況
?????????? ?{"employee_a_info", "employeeAInfo"}?//測試多個(gè)相連字母大寫時(shí)的情況
???? ??});
??}
?
? ?/**
? ?* 參數(shù)化測試必須的構(gòu)造函數(shù)
? ?* @param expected?期望的測試結(jié)果,對(duì)應(yīng)參數(shù)集中的第一個(gè)參數(shù)
? ?* @param target?測試數(shù)據(jù),對(duì)應(yīng)參數(shù)集中的第二個(gè)參數(shù)
? ?*/
??public TestWordDealUtilWithParam(String expected , String target){
???this.expected = expected;
???this.target = target;
??}
?
? ?/**
? ?* 測試將 Java 對(duì)象名稱到數(shù)據(jù)庫名稱的轉(zhuǎn)換
? ?*/
??@Test public void wordFormat4DB(){
???assertEquals(expected, WordDealUtil.wordFormat4DB(target));
??}
}
??????? 很明顯,代碼瘦身了。在靜態(tài)方法 words 中,我們使用二維數(shù)組來構(gòu)建測試所需要的參數(shù)列表,其中每個(gè)數(shù)組中的元素的放置順序并沒有什么要求,只要和構(gòu)造函數(shù)中的順序保持一致就可以了。現(xiàn)在如果再增加一種測試情況,只需要在靜態(tài)方法 words 中添加相應(yīng)的數(shù)組即可,不再需要復(fù)制粘貼出一個(gè)新的方法出來了。
JUnit 和 Ant
??????? 隨著項(xiàng)目的進(jìn)展,項(xiàng)目的規(guī)模在不斷的膨脹,為了保證項(xiàng)目的質(zhì)量,有計(jì)劃的執(zhí)行全面的單元測試是非常有必要的。但單靠JUnit提供的測試套件很難勝任這項(xiàng)工作,因?yàn)轫?xiàng)目中單元測試類的個(gè)數(shù)在不停的增加,測試套件卻無法動(dòng)態(tài)的識(shí)別新加入的單元測試類,需要手動(dòng)修改測試套件,這是一個(gè)很容易遺忘得步驟,稍有疏忽就會(huì)影響全面單元測試的覆蓋率。
??????? 當(dāng)然解決的方法有多種多樣,其中將 JUnit 與構(gòu)建利器 Ant 結(jié)合使用可以很簡單的解決這個(gè)問題。Ant —— 備受贊譽(yù)的 Java 構(gòu)建工具。它憑借出色的易用性、平臺(tái)無關(guān)性以及對(duì)項(xiàng)目自動(dòng)測試和自動(dòng)部署的支持,成為眾多項(xiàng)目構(gòu)建過程中不可或缺的獨(dú)立工具,并已經(jīng)成為事實(shí)上的標(biāo)準(zhǔn)。Ant 內(nèi)置了對(duì) JUnit 的支持,它提供了兩個(gè) Task:junit 和 junitreport,分別用于執(zhí)行 JUnit 單元測試和生成測試結(jié)果報(bào)告。使用這兩個(gè) Task 編寫構(gòu)建腳本,可以很簡單的完成每次全面單元測試的任務(wù)。
不過,在使用 Ant 運(yùn)行 JUnit 之前,您需要稍作一些配置。打開 Eclipse 首選項(xiàng)界面,選擇 Ant -> Runtime 首選項(xiàng)(見圖7),將 JUnit 4.1 的 JAR 文件添加到 Classpath Tab 頁中的 Global Entries 設(shè)置項(xiàng)里。記得檢查一下 Ant Home Entries 設(shè)置項(xiàng)中的 Ant 版本是否在 1.7.0 之上,如果不是請(qǐng)?zhí)鎿Q為最新版本的 Ant JAR 文件。
圖7 Ant Runtime 首選項(xiàng)
????????????????????
??????? 剩下的工作就是要編寫 Ant 構(gòu)建腳本 build.xml。雖然這個(gè)過程稍嫌繁瑣,但這是一件一勞永逸的事情。現(xiàn)在我們就把前面編寫的測試用例都放置到 Ant 構(gòu)建腳本中執(zhí)行,為項(xiàng)目 coolJUnit 的構(gòu)建腳本添加一下內(nèi)容:
<?xml version="1.0"?>
<!-- =============================================
???? auto unittest task???
???? ai92???????????????????????????????????????????????????????????????
???? ========================================== -->
<project name="auto unittest task" default="junit and report" basedir=".">
??<property name="output folder" value="bin"/>
??<property name="src folder" value="src"/>
?
??<property name="test folder" value="testsrc"/>
?
??<property name="report folder" value="report" />
??<!-- - - - - - - - - - - - - - - - - -
????????? target: test report folder init?????????????????????
???????? - - - - - - - - - - - - - - - - - -->
??<target name="test init">
???<mkdir dir="${report folder}"/>
??</target>
?
??<!-- - - - - - - - - - - - - - - - - -
????????? target: compile?????????????????????
???????? - - - - - - - - - - - - - - - - - -->
??<target name="compile">
???<javac srcdir="${src folder}" destdir="${output folder}" />
???<echo>compilation complete!</echo>
??</target>
??<!-- - - - - - - - - - - - - - - - - -
????????? target: compile test cases?????????????????????
???????? - - - - - - - - - - - - - - - - - -->
??<target name="test compile" depends="test init">
???<javac srcdir="${test folder}" destdir="${output folder}" />
???<echo>test compilation complete!</echo>
??</target>
?
??<target name="all compile" depends="compile, test compile">
??</target>
?
??<!-- ========================================
????????? target: auto test all test case and output report file?????????????????????
????? ?===================================== -->
??<target name="junit and report" depends="all compile">
???<junit printsummary="on" fork="true" showoutput="true">
????<classpath>
?????<fileset dir="lib" includes="**/*.jar"/>
?????<pathelement path="${output folder}"/>
????</classpath>
????<formatter type="xml" />
????<batchtest todir="${report folder}">
?????<fileset dir="${output folder}">
??????<include name="**/Test*.*" />
?????</fileset>
????</batchtest>
???</junit>
???<junitreport todir="${report folder}">
????<fileset dir="${report folder}">
?????<include name="TEST-*.xml" />
????</fileset>
????<report format="frames" todir="${report folder}" />
???</junitreport>
??</target>
</project>
??????? Target junit report 是 Ant 構(gòu)建腳本中的核心內(nèi)容,其它 target 都是為它的執(zhí)行提供前期服務(wù)。Task junit 會(huì)尋找輸出目錄下所有命名以“Test”開頭的 class 文件,并執(zhí)行它們。緊接著 Task junitreport 會(huì)將執(zhí)行結(jié)果生成 HTML 格式的測試報(bào)告(圖8)放置在“report folder”下。
??????? 為整個(gè)項(xiàng)目的單元測試類確定一種命名風(fēng)格。不僅是出于區(qū)分類別的考慮,這為 Ant 批量執(zhí)行單元測試也非常有幫助,比如前面例子中的測試類都已“Test”打頭,而測試套件則以“Suite”結(jié)尾等等。
圖8 junitreport 生成的測試報(bào)告
??????????????????????
??????? 現(xiàn)在執(zhí)行一次全面的單元測試變得非常簡單了,只需要運(yùn)行一下 Ant 構(gòu)建腳本,就可以走完所有流程,并能得到一份詳盡的測試報(bào)告。您可以在 Ant 在線手冊(cè) 中獲得上面提及的每一個(gè) Ant 內(nèi)置 task 的使用細(xì)節(jié)。
總結(jié)
??????? 隨著越來越多的開發(fā)人員開始認(rèn)同并接受極限編程(XP)的思想,單元測試的作用在軟件工程中變得越來越重要。本文旨在將最新的單元測試工具 JUnit 4 介紹給您,以及如何結(jié)合 IDE Eclipse 和構(gòu)建工具 Ant 創(chuàng)建自動(dòng)化單元測試方案。并且還期望您能夠通過本文“感染”一些好的單元測試意識(shí),因?yàn)?JUnit 本身僅僅是一份工具而已,它的真正優(yōu)勢來自于它的思想和技術(shù)。
轉(zhuǎn)載于:https://www.cnblogs.com/sunshine-study/p/3652479.html
總結(jié)
以上是生活随笔為你收集整理的(二)单元测试利器 JUnit 4的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 双向环形链表
- 下一篇: 解决EF 4.0 中数据缓存机制