我即將開始尋求利用代碼覆蓋面進行開發，我想知道它如何適合測試驅動開發。TDD和代碼覆蓋率
代碼覆蓋率是事後考慮的嗎？請問您的過程去像
或者你是否在最後運行代碼覆蓋率a許多功能組件已經實施，然後返回並努力實現100％的覆蓋率？
我能想到的第三個選擇是在實現功能之前努力實現100％的覆蓋率。
其中哪些是最常見的，有什麼好處？
在達到100％代碼覆蓋率之前，您不會編寫測試。如果你一直在關注TDD，那麼有沒有被測試所要求的代碼是沒有，所以你應該總是接近100％的覆蓋率。
取而代之，您需要編寫測試，直到所有測試都通過，直到所有測試都已寫入。這意味着所有必需的代碼都被寫入了，因爲如果測試需要它，你只會寫入代碼。
使用TDD時，開發新代碼時應該幾乎總是接近100％，因爲您沒有開發任何不需要通過測試的代碼。只有當你認爲代碼非常簡單以至於你不需要測試（比如說，像C＃中的自動屬性）時，你應該有沒有明確涉及的代碼。您可以通過重構有時引入不必要的塊或以意想不到的方式更改代碼，因此您可能希望在該點使用覆蓋範圍，以確保您沒有意外引入未經測試的代碼。除此之外，我會說我更多地將它用作健康檢查，並定期進行覆蓋率分析，原因相同。當你的紀律失效並且你忽略了以TDD方式工作時，它也可能非常有用。
請記住，你可以有一個測試，實際上使用的代碼被巧合覆蓋。你需要小心這個，尤其是在開始TDD時。哦，我在這個功能，我知道我需要添加這個小薄薄的晚餐薄荷，而我在爲什麼不是另一個薄荷。在你知道它之前，你有一堆未經測試的代碼。
寫測試：失敗 編寫代碼：通過 重構：通過
返回頂部
是啊，我最近開始TDD和驚喜地發現，我就完了之後編寫測試和代碼的一對夫婦我們使用的代碼覆蓋率工具報告了100％的覆蓋率。我不必考慮報道，只是確保我只寫了必要的代碼才能通過測試。如果我發現自己不小心編寫了太多的代碼，我會嘗試隨機發表評論，如果沒有測試突然開始失敗，我知道我沒有編寫足夠的測試。 – SCFrench 2010-06-27 20:22:03