很多公司都有要求程式要寫 Unit Test，Unit Test 固然可以提升程式的品質，但是到底要寫多少 Unit Test 才夠呢? 我想沒有人可以給一個答案。
Code Coverage
Code Coverage 是指程式測試的涵蓋率，但涵蓋率是否要達到 100 percent 才算是好呢 ? 80 % vs 90 % vs 100%，從數據上看 100% 一定是最好的，程式品質最高。
先來看看 Code Coverage 的算法吧，假如我寫了一個檔案 A，檔案 A 裡面共有 10 行程式，然後我再寫一個 Unit Test ，這個 Test 總共有執行了檔案 A 其中 5 行的 Code ，這樣 Code Coverage = 50% 。
從 Code Coverage 的算法來看，Unit Test 只是執行了 5 行程式，但並不代表那 5 行程式就一定會是正確無誤的，一個 function 的測試，不可能單單的靠一個 test 就能夠測試完畢的，通常我們會測試很多種不同的變數型態與區間，來保證程式的正確性。
但就連這樣還是無法保證程式是正確的，別忘了，當我們的功能越來越強大，每一樣功能之間會有關聯性，所以我們必須再花時間去測試每一種關連性，但這些爾外的測試，雖然可以提升程式的品質，卻無法提升 Code Coverage，這就產生了工程師與老闆的盲點。
一個不懂程式也沒有任何 sense 的老闆，當你問大老闆說程式 Code Coverage 的目標要多少，大老闆一定豪不疑問的說 100% ，當然 100% 等同於完美，大老闆當然不想搞死工程師，畢竟專案還是要完成，但是又沒有一個好的方法可以保證程式的正確性，所以大老闆們就會訂出 80 ~ 90 % 之間的標準，要求每一個工程師寫出來的程式，都要完成 Code Coverage 的標準。
我覺得訂出這個標準是一個不負責任的想法， 工程師為了達到 90% 的 Code Coverage ，他就必須花很多的時間，為了一堆不重要的程式，補上 Unit Test ，但是反而沒辦法好好的測試主功能，如果時程上有壓力，最後就會變成程式非常的不穩定， 90% 的 Code Coverage 也只是騙人騙已。
Code Coverage 90 % 的目標，應該要用在一個已經穩定上線的 Project ，對於一個上線中的 Project 來說，工程師已不用追時程、趕專案，這時才會有比較多的時間提升 Code Coverage ，另外一個上線中的專案，需求的變動也會比較小。
若是說我們正在開發一個新的專案，那麼 Code Coverage 就一點也不重要，開發中的專案，很容易因為一開始系統設計不良、或是需求變更、底層 Library 有 Bug 等等因素而改變程式的作法，一旦有變更， 寫過的 Unit Test 就變成了垃圾，而且新改的程式，又要再補上新的 Unit Test，所以對於新專案來說，應該先要求主功能的正確性，然後交由資深的工程師決定有那些功能必需撰寫 Unit Test ， 根據我的經驗，光是將主功能完完整整的測過一遍， Code Coverage 就將近會有 50% 左右了。
Test Code Coverage 小故事
有一天，有一個新手工程師，跑去問大師說：
Code Coverage 要完成多少才行呢?
大師回答
不用管 Code Coverage ，只要寫一些好的 Unit Test 就行了
新人點點頭，就回去工作了。
第二天，另一個工程師，也去跟大師問相同的問題，大師則問工程師說
我應該往這個鍋子裡放多少米呢?
工程師有點困惑，回答說
我無法回答這個問題，這要看有多少人需要吃飯，他們有多餓
「沒錯!」 大師這樣說道，工程師點點頭，就回去工作了。
第三天，又有一個工程師，跑去問大師這個問題，大師用嚴厲的口氣回答說
80 %，不多不少
工程師又點點頭，就回去工作了。
後來，大師的學徒，問大師說為什麼他們問一樣的問題，可是你卻有不同的回答呢，大師站了起來，並回答
第一個工程師是個新手，才剛開始學習如何寫 Unit Test ，他還有很多東西要學習，如果這個時候要求他較高的 Code Coverage 標準，他也無法做到，不如讓他只寫幾個完整的 Unit Test，以後再來想 Code Coveage 的問題；而第二個工程師已經很資深，能夠獨力完成 Coding 與 Unit Test，當我問工程師，鍋裡要放多少米的問題，其實我是想提醒他， Code Coverage 應該要看專案有多少個功能要測試，以及專案的大小，進度，我並不了解工程師正在開發的專案，所以我沒辦法給他一個答案，這個問題必需由他自已找個答案。
學徒又問，即然 Code Coverage 比率是沒辦法隨便訂標準的，那為何你要跟第三個工程師講說「Code Coverage 需達到 80%」呢，大師回答說
第三工程師只想要一個簡單的答案，就算是沒有答案的東西，他也要想要一個數字，而且就算我給他答案，他也不會按照答案的方式做。