您的位置:軟件測試 > 開源軟件測試 > 開源單元測試工具 > junit
JUnit測試的粒度問題
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時(shí)間:[ 2013/5/24 11:28:01 ] 推薦標(biāo)簽:

對于JUnit測試和TDD實(shí)踐中有如下的疑問,請各位解惑:

JUnit測試的粒度如何把握?

簡單的說是針對public的方法寫測試OK了呢?還是說要具體針對public方法中執(zhí)行邏輯的每個(gè)步驟來寫測試方法?

先說一下為什么會(huì)有這種困惑:

業(yè)務(wù)邏輯比較簡單時(shí),當(dāng)然只針對Public方法的業(yè)務(wù)流程來設(shè)計(jì)案例,并只對public方法寫test方法好。

但近做一個(gè)保險(xiǎn)的項(xiàng)目,計(jì)算超復(fù)雜的那種,用戶點(diǎn)一個(gè)Button后臺(tái)要操作十幾張表,數(shù)據(jù)Copy來Copy去

中間還有各種各樣的計(jì)算,設(shè)計(jì)的業(yè)務(wù)Interface方法中接受User的輸入,然后執(zhí)行整個(gè)操作。

現(xiàn)在談一下兩種實(shí)現(xiàn)的方式:

1.按TDD的方式,先寫測試代碼,再寫實(shí)現(xiàn)代碼,實(shí)現(xiàn)過程不斷重構(gòu)(未完整了解過TDD,只是皮毛,如有誤解見諒)

這種方式實(shí)現(xiàn)起來很有難度。首先測試代碼的覆蓋度很難保證:當(dāng)復(fù)雜的業(yè)務(wù)邏輯揉在一個(gè)方法中(即使重構(gòu)拆成若干小方法),流程分支成冪增長,很難一開始把所有的情形都考慮清楚,即使都考慮到了,寫出來的TestCase也可能是超復(fù)雜的,反而會(huì)成為一種負(fù)擔(dān)。

另外,這樣來做實(shí)際上也相當(dāng)于大塊大塊的Coding,然后測試,偏離了TDD的本意,Coding過程中沒辦法保證做的每一步都是正確的,而是將這個(gè)測試推遲到完成了整個(gè)實(shí)現(xiàn)之后。

2.對整個(gè)業(yè)務(wù)邏輯的實(shí)現(xiàn)大致上先分為幾個(gè)步驟,每個(gè)步驟的實(shí)現(xiàn)可以放在protected方法中以便測試,然后再針對每一步來實(shí)踐TDD,這樣沒有上述的兩個(gè)問題,而且終程序員對自己代碼的信心會(huì)大增。但這樣來做也有一些問題。

首先,每一步驟的方法都是protected才能保證測試,這樣破壞了封裝

其次,測試代碼是針對接口實(shí)現(xiàn)的過程來寫的,而不是針對接口的功能,所以測試代碼可能會(huì)很脆弱,實(shí)現(xiàn)過程稍作變化測試代碼也可能要做修改

所以,根本的問題也是單元測試是應(yīng)該針對接口實(shí)現(xiàn)的過程還是接口的功能?

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