對於資料不穩定的討論：[url]
是不是一定要測試到具體數值才叫具體？在沒有找到新方法之前，想保證測試具體到結果或者說是數值準確，那這個測試**會表現的非常脆弱，而花費了很多心思去寫出完美的測試最後這段測試**也沒有測出任何問題，有些得不償失了。
為什麼要寫測試？
都是為了寫出健壯的**，正確的行為，獲得重構的勇氣等等。
好，如果說寫出健壯**需要寫很細粒度的testcase，而且資料庫通常不支援我們這樣做。導致測試很難寫。
我想說，測試是分很多態別的，也可以認為是關注著不同的方向。
比如testcase就要保證我的測試比較完善，包括對結果的驗證，邊界條件檢查等等，這樣的測試包括了我們業務**的方方面面，包括在開發時想到的，沒想到的。通過細粒度來提高我們程式的健壯性。也可以說是逼我們寫出健壯的**。
在比如tdd，其實tdd所關注的是需求，也就是**的行為。他要保證業務**被實現後確實做了我們預想的事情。很多時候我們不太關心testcase的邊界條件，畢竟，客戶要件棉襖，這件棉襖可以過冬就行了，而我們花了很多時間做出了乙個刀槍不入，甚至能穿著去外太空的棉襖，使用者可能永遠都不能用上這些花哨的功能。tdd需要小步快跑。不需要笨重的測試**。
上面兩個簡單例子他們都能為我們提供重構的勇氣。同時可以發現不同的測試方法對於測試的關注點是不一樣的。
void testgetsomereport()
這樣就行了，這樣的測試關注的是我的dao是否被執行，如果執行表結構是否支援（如果表結構更變會得到通知）。而且對資料的依賴非常小。我們根本不需要去驗證他們。現階段我們只要保證所有的流程都會在測試中執行，這樣就可以了。
如果進行重構這些反映**行為的測試會告知重構者，他們是做什麼的，當時的那個程式設計師的思考過程。這已經足夠了，如果你不能保證重構之後的結果依然正確，就暫時不要去觸碰他，等你有足夠能力去保證產出的**可以有正確結果之後在考慮這些。
由於我們暫時還不能得到穩定的測試資料，所以準備採用測試行為的方式。而更少去關注細節。對於業務型**，粒度會加細。
由於推廣測試的路途坎坷，不能一下子全部搞好，所以，準備先以粗粒度進行，並且保證覆蓋度。
JUnit測試的粒度問題
對於junit測試和tdd實踐中有如下的疑問，請各位解惑 junit測試的粒度如何把握？簡單的說是針對public的方法寫測試就ok了呢？還是說要具體針對public方法中執行邏輯的每個步驟來寫測試方法？先說一下為什麼會有這種困惑 業務邏輯比較簡單時，當然只針對public方法的業務流程來設計案例，...
如何控制單元測試的粒度？
john nolan在 how deep are your unit tests?中問道 u0026 xd n u0026 xd n tdd需要花時間寫測試，而我們一般多少會寫一些 而第乙個測試是測試我的建構函式有沒有把這個類的變數都設定對了，這會不會太過分了？那麼，我們寫單元測試的這個單元的粒度到...
測試總監的第二封回信, 小王還應該繼續做測試嗎
上下文請參考前兩篇 小王是乙個測試團隊的新成員,遇上這個情況應該怎麼辦?測試總監的第一封回信,然後小王又問了第二個問題 小王的第二個問題是 現在專案比較被動,作為測試人員,我會按照上面的標準,盡量把產品缺陷提前找出來,並且堅持上訴原則,確保產品質量.但是這麼多bug都一定要堅持修的話,看來推遲產品發...