許多公司往往為了 KPI 需要數字，所以將測試覆蓋率訂了個 criteria 來「強暴」開發團隊，甚至要求團隊「一定」要用 TDD 來開發所有程式。
這一切都是不求甚解的為了潮、為了追求數字的迷思，本篇文章將補上我對於「測試覆蓋率」與「看待 TDD 的正確角度」的見解。
前言
在微信與 Facebook 上看到大家轉發的一篇文章：100％代码覆盖率的悲剧。我剛好從這篇文章，來對測試覆蓋率跟 TDD 做一些補充。
有了目標我們再來看別的東西，就清楚多了。
WHY TDD？
如果你不知道怎麼簡單設計，TDD 可以幫助你，但你不一定非得要用它。
如果你不知道怎麼設計出讓呼叫端易用的 API，那 TDD 可以幫助你，但你不一定非得用它。
如果你想要讓測試案例被自動化生成文件，你應該先問一下，你產生出來的文件效益在哪，如果沒有，那你不一定需要它。
CODE COVERAGE CRITERIA？
針對 code coverage 的部分，如我在培訓課程上提到的，在團隊中若真要給個 criteria，我會建議測試覆蓋率至少 > 0%，也就是應該要有測試。這原因是，讓後續的人只需要加測試案例即可，不需要自己建測試專案、拉參考、設定 CI config，後手的人不用從無到有，只需要新增測試程式就好，這樣就會減少很多心裡的抗拒。
接著要求的重點在於「相對趨勢 > 絕對數字」，與其去訂一個覆蓋率 > 20 %, 還不如定義，每次 build 之後，coverage 只能比原本的高，這意義是對自己這次簽入的程式碼負責。（無須對前人的 legacy code 負責）
接著鼓勵大家頻繁簽入，整體程式碼的覆蓋率就會不斷提昇。
Code Coverage 的比例向來不是重點，有數字時大家就只會迷思在數字，這是 KPI 思維，不是 OKR。
要去調研的應該是：「那些沒被覆蓋到的產品代碼，發生什麼事了？」
是有需求存在，但漏了測試案例？它重要嗎？值得補嗎？
還是根本需求已經不存在，這只是段 legacy code, 這段產品代碼根本沒有存在的必要了。那就清掉它。
這才是看待測試覆蓋率的正確方式。
結論
- 測試覆蓋率的數字不是重點，辨識哪一些代碼沒被測試覆蓋到，所代表的意義才是重點。
- 相對趨勢 > 絕對數字，每個人願意為自己的部分負責（就像擦自己屁股總是甘願一點，擦別人屁股總覺得髒），測試覆蓋率只能往上提昇，不能往下掉，接著鼓勵頻繁簽入。
- TDD 是種手段，是達成目的的一種很好用、很值得投資的方式，把 TDD 當作達成目的的一種方式，而不是把 TDD 當作目標。嚴格來說，TDD 是一個好的開發習慣。
blog 與課程更新內容，請前往新站位置：http://tdd.best/
