john nolan在《how deep are your unit tests?》中問道：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\ntdd需要花時間寫測試，而我們一般多少會寫一些**，而第乙個測試是測試我的建構函式有沒有把這個類的變數都設定對了，這會不會太過分了？那麼，我們寫單元測試的這個單元的粒度到底是什麼樣的？並且，是不是我們的測試測試得多了點？
\u0026#xd;\n
最佳答案是：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n老闆為我的**付報酬，而不是測試，所以，我對此的價值觀是——測試越少越好，少到你對你的**質量達到了某種自信（我覺得這種的自信標準應該要高於業內的標準，當然，這種自信也可能是種自大）。如果我的編碼生涯中不會犯這種典型的錯誤（如：在建構函式中設了個錯誤的值），那我就不會測試它。我傾向於去對那些有意義的錯誤做測試，所以，我對一些比較複雜的條件邏輯會異常地小心。當在乙個團隊中，我會非常小心的測試那些會讓團隊容易出錯的**。
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n只是要地球人都不會覺得kent beck會這麼說啊！我們有大堆程式設計師在忠實的追求著100%的**測試覆蓋率，因為這些程式設計師覺得kent beck也會這麼幹！我告訴過很多人，你在你的xp的書裡說過，你並不總是支援「宗教信仰式的test first」，但是今天kent這麼說，我還是很驚訝！
\u0026#xd;\n
陳皓則是非常同意kent的回答：「怎麼合適怎麼搞，愛怎麼測試就怎麼測試，只要自己和團隊有信心就可以了。沒有必要就一定要寫測試，一定要測試先行。」
\u0026#xd;\n
其他排名靠前的***括：
\u0026#xd;\n
dominic rodger
\u0026#xd;\n
為可能會出錯的地方和邊界情況編寫單元測試。另外，單元測試應該跟著缺陷報告走，在修補缺陷之前編寫好單元測試。開發人員就會對**充滿自信：一是bug已經修補，二是bug不會重現。
\u0026#xd;\n
kitofr
\u0026#xd;\n
最後，陳皓表達了自己的觀點：
\u0026#xd;\n
infoq的讀者朋友對此有何自己的見解？
控制單元的功能
控制單元 控制單元具有發出各種微操作命令 即控制訊號 序列的功能。概括地說，計算機的功能就是執行程式。在執行程式的過程中，控制單元要發出各種微操作命令，而且不同的指令對應不同的命令。進一步分析發現，完成不同指令的過程中，有些操作是相同或相似的，如取指令 取運算元位址 當間接定址時 以及進入中斷週期由...
如何設計單元測試
在開發過程中，經常要遇到的問題是怎麼保證 的質量，保證 正常執行？單元測試就是一種保證 質量的途徑。好的單元測試可以維護好程式，特別是在需要重構的時候。那麼怎麼樣設計好我們的單元測試呢？下面提供下一些思路 根據輸入和輸出，劃分為輸入等價類和輸出等價類 根據輸入和輸出的範圍邊界進行測試，一般是等價類的...
單元測試系列二 單元測試如何測試異常與超時
一 測試異常 1.使用 test的expected屬性測試異常 第一種方式，使用expected屬性 test expected filenotfoundexception.class public void usingexpected throws filenotfoundexception2.使...