James Shore：不要使用單元測試的程式碼覆蓋率
如果您正在使用測試驅動開發，請不要衡量單元測試的程式碼覆蓋率，這比無用的統計更糟糕; 它會積極地引導你誤入歧途。
你應該怎麼做？這取決於你想要完成什麼。
改進程式碼和測試實踐
如果您正在嘗試改進團隊的編碼和測試實踐，請執行轉義缺陷的根本原因分析1，然後改進您的設計和流程， 以防止再次發生此類缺陷。
如果等待缺陷逃逸對您來說風險太大，那麼經驗豐富的QA測試人員會進行探索性測試 並對結果進行根本原因分析，無論哪種方式，這裡的想法是分析您的Bug，以瞭解要改進的內容，程式碼覆蓋率不會告訴您。
提高程式設計師程式碼質量
如果您正在嘗試提高程式設計師的程式碼質量，教授測試技能，加快測試迴圈，重構更多，使用進化設計，並嘗試結對程式設計或mob程式設計。
教授測試技能並加快測試迴圈，使程式設計師更容易編寫有價值的測試。測試覆蓋範圍不會做到的， 它只是鼓勵編寫毫無價值的測試來使數字上升。
重構更多並使用進化設計使您的設計更簡單，更易於理解。這減少了與設計相關的缺陷。
結對程式設計或mob程式設計可以增強團隊的自律能力，每個人偶爾都會感到懶惰，但是當你結對程式設計或mob程式設計時，所涉及的每個人只會在同一時間變得懶惰。它還使您的程式碼質量更高，更易於理解，因為協同工作可以讓程式設計師看到彼此程式碼中的弱點，並提出更優雅的解決方案。
改善測試紀律
有些人使用程式碼覆蓋率指標來強化他們想要的習慣。不幸的是，習慣不能強制執行，只能培養。我想起了一個我工作的地方，管理者想要好的程式碼提交日誌。他們配置了他們的工具來對每次提交強制執行註釋。他們最常見的評論是啥？“a” ，後來他們更改了工具，以便在每次提交時強制執行多字註釋。現在最常見的評論是“aa a”。
執法不會改變思想。相反，使用輔導和學科增強實踐，如結對程式設計或mob程式設計。
提高要求程式碼質量
如果您正在努力改善程式碼滿足客戶需求的程度，請儘早讓客戶代表參與進來，例如在“早期Sprint結束之前”。他們不會總是立刻告訴你你錯過了什麼，但是你越早給他們機會這樣做，你就越有可能學到你需要知道的東西。
提高非功能性質量
如果您正在嘗試提高可靠性或效能等“非功能”特性，請使用實際監控，使用故障快速程式碼 和專用測試平臺。非功能屬性作為一個整體從系統中出現，因此即使是覆蓋率為100％的程式碼庫也會出現問題。
這是關於TDD的事情
TDD的定義是，如果沒有失敗的測試，您就不會編寫程式碼，而是在一次覆蓋一個分支的緊密迴圈中執行此操作。所以，如果你正在做TDD，你的任何程式碼要覆蓋是依據事實覆蓋。如果你仍然有缺陷，那麼別的東西就錯了。
如果人們不知道如何正確地進行TDD，程式碼覆蓋率指標將無濟於事。如果他們不想覆蓋他們的程式碼，程式碼覆蓋率指標將無濟於事。如果出現其他問題，您就明白了，程式碼覆蓋率指標無濟於事。他們充其量只是一種分心，而且是最糟糕的遊戲指標。找出你真正想要改進的內容並直接關注它。
PS:Ryan Norris 在Twitter上有一個很棒的故事 ，關於程式碼覆蓋如何幫助他的團隊扭轉遺留程式碼庫。Martin Fowler 寫過 關於偶爾的程式碼覆蓋率審查是如何有用的健全性檢查。