您的位置:軟件測(cè)試 > 開源軟件測(cè)試 > 開源單元測(cè)試工具 > junit
JUnit測(cè)試教程
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時(shí)間:[ 2013/8/26 14:42:48 ] 推薦標(biāo)簽:

如果你立即動(dòng)手寫了上面的代碼,你會(huì)發(fā)現(xiàn)兩個(gè)問題,第一,如果你要執(zhí)行測(cè)試的類testCar,你必須必須手工敲入如下命令:
[Windows] d:>java testCar
[Unix] % java testCar
即便測(cè)試如例示的那樣簡(jiǎn)單,你也有可能不愿在每次測(cè)試的時(shí)候都敲入上面的命令,而希望在某個(gè)集成環(huán)境中(IDE)點(diǎn)擊一下鼠標(biāo)能執(zhí)行測(cè)試。后面的章節(jié)會(huì)介紹到這些問題。第二,如果沒有一定的規(guī)范,測(cè)試類的編寫將會(huì)成為另一個(gè)需要定義的標(biāo)準(zhǔn)。沒有人希望查看別人是如何設(shè)計(jì)測(cè)試類的。如果每個(gè)人都有不同的設(shè)計(jì)測(cè)試類的方法,光維護(hù)被測(cè)試的類夠煩了,誰(shuí)還顧得上維護(hù)測(cè)試類?另外有一點(diǎn)我不想提,但是這個(gè)問題太明顯了,測(cè)試類的代碼多于被測(cè)試的類!這是否意味這雙倍的工作?不!1)不論被測(cè)試類-Car 的 getWheels 方法如何復(fù)雜,測(cè)試類-testCar 的testGetWheels 方法只會(huì)保持一樣的代碼量。2)提高軟件的質(zhì)量并解決軟件熵這一問題并不是沒有代價(jià)的。testCar是代價(jià)。
我們目前所能做的是盡量降低所付出的代價(jià):我們編寫的測(cè)試代碼要能被維護(hù)人員容易的讀取,我們編寫測(cè)試代碼要有一定的規(guī)范。好IDE工具可以支持這些規(guī)范。 好了,你所需要的是JUnit。一個(gè)Open Source的項(xiàng)目。用其主頁(yè)上的話來(lái)說(shuō)是:“JUnit是由 Erich Gamma 和 Kent Beck 編寫的一個(gè)回歸測(cè)試框架(regression testing work)。用于Java開發(fā)人員編寫單元測(cè)試之用。”所謂框架是 Erich Gamma 和 Kent Beck 定下了一些條條框框,你編寫的測(cè)試代碼必須遵循這個(gè)條條框框:繼承某個(gè)類,實(shí)現(xiàn)某個(gè)接口。其實(shí)也是我們前面所說(shuō)的規(guī)范。好在JUnit目前得到了大多數(shù)軟件工程師的認(rèn)可。遵循JUnit我們會(huì)得到很多的支持;貧w測(cè)試是你不斷地對(duì)所編寫的代碼進(jìn)行測(cè)試:編寫一些,測(cè)試一些,調(diào)試一些,然后循環(huán)這一過(guò)程,你會(huì)不斷地重復(fù)先前的測(cè)試,哪怕你正編寫其他的類,由于軟件熵的存在,你可能在編寫第五個(gè)類的時(shí)候發(fā)現(xiàn),第五個(gè)類的某個(gè)操作會(huì)導(dǎo)致第二個(gè)類的測(cè)試失敗。通過(guò)回歸測(cè)試我們抓住了這條大Bug。

回歸測(cè)試框架-JUnit
通過(guò)前面的介紹,我們對(duì)JUnit有了一個(gè)大概的輪廓。知道了它是干什么的,F(xiàn)在讓我們動(dòng)手改寫上面的測(cè)試類testCar使其符合Junit的規(guī)范--能在JUnit中運(yùn)行。
//執(zhí)行測(cè)試的類(JUnit版)
import junit.work.*;
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)面目全非。先讓我們了解這些改動(dòng)都是什么含義,再看如何執(zhí)行這個(gè)測(cè)試。
1>import語(yǔ)句,引入JUnit的類。(沒問題吧)
2>繼承 TestCase ?梢詴簳r(shí)將一個(gè)TestCase看作是對(duì)某個(gè)類進(jìn)行測(cè)試的方法的集合。詳細(xì)介紹請(qǐng)參看JUnit資料
3>setUp()設(shè)定了進(jìn)行初始化的任務(wù)。我們以后會(huì)看到setUp會(huì)有特別的用處。
4>testGetWheeels()對(duì)預(yù)期的值和myCar.getWheels()返回的值進(jìn)行比較,并打印比較的結(jié)果。assertEquals是junit.work.Assert中所定義的方法,junit.work.TestCase繼承了junit.work.Assert。
5>suite()是一個(gè)很特殊的靜態(tài)方法。JUnit的TestRunner會(huì)調(diào)用suite方法來(lái)確定有多少個(gè)測(cè)試可以執(zhí)行。上面的例子顯示了兩種方法:靜態(tài)的方法是構(gòu)造一個(gè)內(nèi)部類,并利用構(gòu)造函數(shù)給該測(cè)試命名(test name, 如 Car.getWheels ),其覆蓋的runTest()方法,指明了該測(cè)試需要執(zhí)行那些方法--testGetWheels()。動(dòng)態(tài)的方法是利用內(nèi)省(reflection )來(lái)實(shí)現(xiàn)runTest(),找出需要執(zhí)行那些測(cè)試。此時(shí)測(cè)試的名字即是測(cè)試方法(test method,如testGetWheels)的名字。JUnit會(huì)自動(dòng)找出并調(diào)用該類的測(cè)試方法。
6>將TestSuite看作是包裹測(cè)試的一個(gè)容器。如果將測(cè)試比作葉子節(jié)點(diǎn)的話,TestSuite是分支節(jié)點(diǎn)。實(shí)際上TestCase,TestSuite以及TestSuite組成了一個(gè)composite Pattern。 JUnit的文檔中有一篇專門講解如何使用Pattern構(gòu)造Junit框架。有興趣的朋友可以查看JUnit資料。
如何運(yùn)行該測(cè)試呢?手工的方法是鍵入如下命令:
[Windows] d:>java junit.textui.TestRunner testCar
[Unix] % java junit.textui.TestRunner testCar

上一頁(yè)123456下一頁(yè)
軟件測(cè)試工具 | 聯(lián)系我們 | 投訴建議 | 誠(chéng)聘英才 | 申請(qǐng)使用列表 | 網(wǎng)站地圖
滬ICP備07036474 2003-2017 版權(quán)所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd