對于JUnit測試和TDD實踐中有如下的疑問，請各位解惑：
JUnit測試的粒度如何把握？
簡單的說是針對public的方法寫測試OK了呢？還是說要具體針對public方法中執行邏輯的每個步驟來寫測試方法？
先說一下為什么會有這種困惑：
業務邏輯比較簡單時，當然只針對Public方法的業務流程來設計案例，并只對public方法寫test方法好。
但近做一個保險的項目，計算超復雜的那種，用戶點一個Button后臺要操作十幾張表，數據Copy來Copy去
中間還有各種各樣的計算，設計的業務Interface方法中接受User的輸入，然后執行整個操作。
現在談一下兩種實現的方式：
1.按TDD的方式，先寫測試代碼，再寫實現代碼，實現過程不斷重構(未完整了解過TDD，只是皮毛，如有誤解見諒)
這種方式實現起來很有難度。首先測試代碼的覆蓋度很難保證：當復雜的業務邏輯揉在一個方法中(即使重構拆成若干小方法)，流程分支成冪增長，很難一開始把所有的情形都考慮清楚，即使都考慮到了，寫出來的TestCase也可能是超復雜的，反而會成為一種負擔。
另外，這樣來做實際上也相當于大塊大塊的Coding，然后測試，偏離了TDD的本意，Coding過程中沒辦法保證做的每一步都是正確的，而是將這個測試推遲到完成了整個實現之后。
2.對整個業務邏輯的實現大致上先分為幾個步驟，每個步驟的實現可以放在protected方法中以便測試，然后再針對每一步來實踐TDD，這樣沒有上述的兩個問題，而且終程序員對自己代碼的信心會大增。但這樣來做也有一些問題。
首先，每一步驟的方法都是protected才能保證測試，這樣破壞了封裝
其次，測試代碼是針對接口實現的過程來寫的，而不是針對接口的功能，所以測試代碼可能會很脆弱，實現過程稍作變化測試代碼也可能要做修改
所以，根本的問題也是單元測試是應該針對接口實現的過程還是接口的功能？
