JUnit測試的粒度問題

對於junit測試和tdd實踐中有如下的疑問，請各位解惑：

junit測試的粒度如何把握？

簡單的說是針對public的方法寫測試就ok了呢？還是說要具體針對public方法中執行邏輯的每個步驟來寫測試方法？

先說一下為什麼會有這種困惑：

業務邏輯比較簡單時，當然只針對public方法的業務流程來設計案例，並只對public方法寫test方法就好。

但最近做乙個保險的專案，計算超複雜的那種，使用者點乙個button後台要操作十幾張表，資料copy來copy去

中間還有各種各樣的計算，設計的業務inte***ce方法中接受user的輸入，然後執行整個操作。

現在談一下兩種實現的方式：

1.按tdd的方式，先寫測試**，再寫實現**，實現過程不斷重構(未完整了解過tdd，只是皮毛，如有誤解見諒)

這種方式實現起來很有難度。首先測試**的覆蓋度很難保證：當複雜的業務邏輯揉在乙個方法中(即使重構拆成若干小方法)，流程分支成冪增長，很難一開始就把所有的情形都考慮清楚，即使都考慮到了，寫出來的testcase也可能是超複雜的，反而會成為一種負擔。

另外，這樣來做實際上也就相當於大塊大塊的coding,然後測試，偏離了tdd的本意，coding過程中沒辦法保證做的每一步都是正確的，而是將這個測試推遲到完成了整個實現之後。

2.對整個業務邏輯的實現大致上先分為幾個步驟，每個步驟的實現可以放在protected方法中以便測試，然後再針對每一步來實踐tdd，這樣沒有上述的兩個問題，而且最終程式設計師對自己**的信心會大增。但這樣來做也有一些問題。

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

其次，測試**是[b]針對介面實現的過程[/b]來寫的，而不是[b]針對介面的功能[/b]，所以測試**可能會很脆弱，實現過程稍作變化測試**也可能要做修改

所以，最根本的問題也就是單元測試是應該針對介面實現的過程還是介面的功能？