對(duì)于JUnit測(cè)試和TDD實(shí)踐中有如下的疑問(wèn)，請(qǐng)各位解惑：

JUnit測(cè)試的粒度如何把握？

簡(jiǎn)單的說(shuō)是針對(duì)public的方法寫測(cè)試OK了呢？還是說(shuō)要具體針對(duì)public方法中執(zhí)行邏輯的每個(gè)步驟來(lái)寫測(cè)試方法？

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

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

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

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

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

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

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

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

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

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

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

所以，根本的問(wèn)題也是單元測(cè)試是應(yīng)該針對(duì)接口實(shí)現(xiàn)的過(guò)程還是接口的功能？