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

別擔(dān)心你要敲的字符量,以后在IDE中,只要點(diǎn)幾下鼠標(biāo)成了。運(yùn)行結(jié)果應(yīng)該如下所示,表明執(zhí)行了一個(gè)測(cè)試,并通過(guò)了測(cè)試:
.
Time: 0
OK (1 tests)
如果我們將Car.getWheels()中返回的的值修改為3,模擬出錯(cuò)的情形,則會(huì)得到如下結(jié)果:
.F
Time: 0
There was 1 failure:
1) testGetWheels(testCar)junit.work.AssertionFailedError: expected:<4> but was:<3>
at testCar.testGetWheels(testCar.java:37)
FAILURES!!!
Tests run: 1, Failures: 1, Errors: 0
注意:Time上的小點(diǎn)表示測(cè)試個(gè)數(shù),如果測(cè)試通過(guò)則顯示OK。否則在小點(diǎn)的后邊標(biāo)上F,表示該測(cè)試失敗。注意,在模擬出錯(cuò)的測(cè)試中,我們會(huì)得到詳細(xì)的測(cè)試報(bào)告“expected:<4> but was:<3>”,這足以告訴我們問(wèn)題發(fā)生在何處。下面是你調(diào)試,測(cè)試,調(diào)試,測(cè)試...的過(guò)程,直至得到期望的結(jié)果。

Design by Contract(這句話我沒(méi)法翻譯)
Design by Contract本是Bertrand Meyer(Eiffel語(yǔ)言的創(chuàng)始人)開(kāi)發(fā)的一種設(shè)計(jì)技術(shù)。我發(fā)現(xiàn)在JUnit中使用Design by Contract會(huì)帶來(lái)意想不到的效果。Design by Contract的核心是斷言(assersion)。斷言是一個(gè)布爾語(yǔ)句,該語(yǔ)句不能為假,如果為假,則表明出現(xiàn)了一個(gè)bug。Design by Contract使用三種斷言:前置條件(pre-conditions)、后置條件(post-conditions)和不變式(invariants)這里不打算詳細(xì)討論Design by Contract的細(xì)節(jié),而是希望其在測(cè)試中能發(fā)揮其作用。
前置條件在執(zhí)行測(cè)試之前可以用于判斷是否允許進(jìn)入測(cè)試,即進(jìn)入測(cè)試的條件。如 expectedWheels > 0, myCar != null。后置條件用于在測(cè)試執(zhí)行后判斷測(cè)試的結(jié)果是否正確。如 expectedWheels==myCar.getWheels()。而不變式在判斷交易(Transaction)的一致性(consistency)方面尤為有用。我希望JUnit可以將Design by Contract作為未來(lái)版本的一個(gè)增強(qiáng)。

Refactoring(這句話我依然沒(méi)法翻譯)
Refactoring本來(lái)與測(cè)試沒(méi)有直接的聯(lián)系,而是與軟件熵有關(guān),但既然我們說(shuō)測(cè)試能解決軟件熵問(wèn)題,我們也必須說(shuō)出解決之道。(僅僅進(jìn)行測(cè)試只能發(fā)現(xiàn)軟件熵,Refactoring則可解決軟件熵帶來(lái)的問(wèn)題。)軟件熵引出了一個(gè)問(wèn)題:是否需要重新設(shè)計(jì)整個(gè)軟件的結(jié)構(gòu)?理論上應(yīng)該如此,但現(xiàn)實(shí)不允許我們這么做。這或者是由于時(shí)間的原因,或者是由于費(fèi)用的原因。重新設(shè)計(jì)整個(gè)軟件的結(jié)構(gòu)會(huì)給我們帶來(lái)短期的痛苦。而不停地給軟件打補(bǔ)丁甚至是補(bǔ)丁的補(bǔ)丁則會(huì)給我們帶來(lái)長(zhǎng)期的痛苦。(不管怎樣,我們總處于水深火熱之中)
Refactoring是一個(gè)術(shù)語(yǔ),用于描述一種技術(shù),利用這種技術(shù)我們可以免于重構(gòu)整個(gè)軟件所帶來(lái)的短期痛苦。當(dāng)你refactor時(shí),你并不改變程序的功能,而是改變程序內(nèi)部的結(jié)構(gòu),使其更易理解和使用。如:該變一個(gè)方法的名字,將一個(gè)成員變量從一個(gè)類(lèi)移到另一個(gè)類(lèi),將兩個(gè)類(lèi)似方法抽象到父類(lèi)中。所作的每一個(gè)步都很小,然而1-2個(gè)小時(shí)的Refactoring工作可以使你的程序結(jié)構(gòu)更適合目前的情況。Refactoring有一些規(guī)則:
1> 不要在加入新功能的同時(shí)refactor已有的代碼。在這兩者間要有一個(gè)清晰的界限。如每天早上1-2個(gè)小時(shí)的Refactoring,其余時(shí)間添加新的功能。
2> 在你開(kāi)始Refactoring前,和Refactoring后都要保證測(cè)試能順利通過(guò)。否則Refactoring沒(méi)有任何意義。
3> 進(jìn)行小的Refactoring,大的不是Refactoring了。如果你打算重構(gòu)整個(gè)軟件,沒(méi)有必要Refactoring了。
只有在添加新功能和調(diào)試bug時(shí)才又必要Refactoring。不要等到交付軟件的后關(guān)頭才Refactoring。那樣和打補(bǔ)丁的區(qū)別不大。Refactoring 用在回歸測(cè)試中也能顯示其威力。要明白,我不反對(duì)打補(bǔ)丁,但要記住打補(bǔ)丁是應(yīng)該后使用的必殺絕招。(打補(bǔ)丁也需要很高的技術(shù),詳情參看微軟網(wǎng)站)

IDE對(duì)JUnit的支持
目前支持JUnit的Java IDE 包括 IDE 方式 個(gè)人評(píng)價(jià)(1-5,滿分5)
Forte for Java 3.0 Enterprise Edition plug-in 3
JBuilder 6 Enterprise Edition integrated with IDE 4
Visual Age for Java support N/A
在IDE中如何使用JUnit,是非常具體的事情。不同的IDE有不同的使用方法。一旦理解了JUnit的本質(zhì),使用起來(lái)十分容易了。所以我們不依賴(lài)于具體的IDE,而是集中精力講述如何利用JUnit編寫(xiě)單元測(cè)試代碼。心急的人可參看資料。

JUnit簡(jiǎn)介
既然我們已經(jīng)對(duì)JUnit有了一個(gè)大致的了解,我希望能給大家提供一個(gè)稍微正式一些的編寫(xiě)JUnit測(cè)試文檔的手冊(cè),明白其中的一些關(guān)鍵術(shù)語(yǔ)和概念。但我要聲明的是這并不是一本完全的手冊(cè),只能認(rèn)為是一本入門(mén)手冊(cè)。同其他OpenSource的軟件有同樣的問(wèn)題,JUnit的文檔并沒(méi)有商業(yè)軟件文檔的那種有規(guī)則,簡(jiǎn)潔和完全。由開(kāi)發(fā)人員編寫(xiě)的文檔總是說(shuō)不太清楚問(wèn)題,全整的文檔需要參考"官方"指南,API手冊(cè),郵件討論組的郵件,甚至包括源代碼中及相關(guān)的注釋。
事實(shí)上問(wèn)題并沒(méi)有那么復(fù)雜,除非你有非常特別的要求,否則,只需參考本文你可以得到所需的大部分信息。

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