TDD。什麼時候可以繼續？

Question

在做TDD時，如何判斷「對於這個類/功能是否足夠的測試」？

I.e.你什麼時候可以告訴你完成了所有邊界案例的測試？

Answer 1

隨着測試驅動開發，你將你寫測試代碼之前編寫測試。一旦你編寫了代碼並通過了測試，那麼現在是編寫另一個測試的時候了。如果你正確地遵循TDD，一旦你的代碼完成了所有必要的測試，你就已經編寫了足夠的測試。

至於邊緣的情況下，讓我們採取一個實例，例如在一個方法驗證的參數。在向代碼添加參數之前，您需要創建測試來驗證代碼是否正確處理每個事件。然後你可以添加參數和相關邏輯，並確保測試通過。如果你想出更多的邊緣案例，那麼可以添加更多的測試。

通過採取它在一步一個腳印，你會不會擔心邊緣情況下，當你寫完你的代碼，因爲你已經寫了他們所有的測試。當然，總會有人爲錯誤，並且你可能會錯過某些東西......當這種情況發生時，是時候添加另一個測試然後修復代碼。

Answer 2

那麼，當你想不出任何比較失敗的情況下，按預期不起作用。 TDD的

部分就是保持你想要實現的東西，問題的清單與您當前執行......所以，當該列表用完了，你基本上是做了....

記住，您可以隨時返回並在您發現實施中的錯誤或新問題時添加測試。

Answer 3

您可以隨時使用測試覆蓋率工具，如EMMA（http://emma.sourceforge.net/）或其Eclipse插件EclEmma（http://www.eclemma.org/）等。一些開發人員認爲100％的測試覆蓋率是一個有價值的目標;其他人不同意。

Answer 4

那常識，沒有完美的答案。 TDD的目標是消除恐懼心理，如果你覺得你有信心測試不夠好去...

只是不要忘記，如果您發現錯誤後，先寫一個測試來重現錯誤，然後正確它，所以你會阻止未來的變化再次打破它！

有些人抱怨，當他們沒有百分之X的覆蓋率....一些測試是無用的，100％的覆蓋率並不意味着你測試了所有可以讓你的代碼破壞的事情，只有它不會破壞的事實你用它的方式！

Answer 5

只是試圖想出任何可能導致某些事情失敗的原因。空值，值超出範圍等。一旦你不能輕易想出任何東西，繼續到別的東西。

如果在路上你發現一個新的bug或者想出一個辦法，添加測試。

這不是代碼覆蓋。這是一個危險的指標，因爲代碼在「測試良好」之前很久就被「覆蓋」了。

Answer 6

在一定程度上，它是

一個直覺：「我是有信心的是，測試將捕獲所有我現在能想到的 的問題？「

在另一個層面上，你已經有了一組必須滿足用戶或系統的要求，所以你可以停在那裏。

雖然我使用的代碼覆蓋率，如果告訴我，我沒有遵循我的TDD流程，找到可以刪除的代碼，我不會將代碼覆蓋率作爲知道何時停止的有用方法。您的代碼覆蓋率可能爲100％，但如果您忘記了包含需求，那麼，那麼你並沒有真正做完，是嗎

也許對TDD的一個誤解是你必須知道的一切前面測試。這是錯誤的，因爲TDD過程產生的測試就像麪包屑痕跡。你知道過去測試過的東西，並且可以在一定程度上引導你，但它不會告訴你下一步該做什麼。

我認爲TDD可以被認爲是一個進化過程。也就是說，你從最初的設計開始，它是一系列測試。當您的代碼在生產中遭到破壞時，您會添加更多測試以及使這些測試通過的代碼。每次你在這裏添加一個測試，並在那裏進行一個測試時，你也在做TDD，而且它不會花費太多。當你編寫第一組測試時，你不知道這些情況是否存在，但是你現在已經獲得了知識，只需按一下按鈕就可以檢查這些問題。這是TDD的巨大力量，也是我爲此提倡的原因之一。

Answer 7

也許我錯過了Agile/XP世界的某個地方，但我對這個過程的理解是開發者和客戶指定了測試作爲功能的一部分。這允許測試用例替代更正式的需求文檔，幫助確定特性的用例等等。所有這些測試都通過時，您就完成了測試和編碼......再加上您認爲的更多邊緣案例一路走來

Answer 8

阿爾貝託薩沃亞says即「如果你所有的測試通過，很可能是你的測試不夠好」。我認爲這是考慮測試的好方法：詢問你是否在做邊緣案例，通過一些意想不到的參數等等。提高測試質量的好方法是與一對測試人員（特別是測試人員）合作，並獲得更多測試用例的幫助。與測試人員配對很好，因爲他們有不同的觀點。

當然，您可以使用一些工具來做mutation tests並從您的測試中獲得更多的信心。我已經使用Jester，它改進了我的測試和我寫他們的方式。考慮使用類似的東西。

親切的問候

Answer 9

理論上你應該覆蓋所有可能的輸入組合和測試輸出是正確的，但有時它只是不值得。

Answer 10

許多其他評論已經成爲頭上的釘。在測試範圍內，您對自己編寫的代碼有信心嗎？隨着你的代碼的發展，你的測試還能充分覆蓋它嗎？你的測試是否捕獲被測組件的預期行爲和功能？

必須有一個快樂的媒介。隨着您添加越來越多的測試用例，您的測試可能會變得很脆弱，因爲所考慮的邊緣案例會不斷髮生變化。遵循許多早期的建議，可以非常有幫助地獲得您可以預先考慮的所有內容，然後隨着軟件的發展添加新的測試。這種有機增長可以幫助您的測試成長，而不需要預先付出所有的努力。

我不會說謊，但我回去寫額外的測試時經常懶惰。我可能會錯過包含0代碼的屬性或我不關心的默認構造函數。有時候並不完全扼殺這個過程可以爲您節省時間n那些不太重要的領域（100％代碼覆蓋率的神話）。

你必須記住，最終目標是獲得一流的產品出門，而不是殺了自己的測試。如果你有這種直覺，就像你錯過了某些東西，那麼你有機會，並且你需要添加更多的測試。

祝你好運，快樂編碼。

Answer 11

測試是一種精確描述你想要的東西的方法。添加一個測試擴展你想要的範圍，或者增加你想要的細節。

如果你不能想到更多你想要的東西，或者任何你想要的東西的改進，那麼就轉向其他東西。你可以隨時回來。

Answer 12

測試在TDD約爲覆蓋說明書，實際上它們可以是一個規範替代。在TDD中，測試不涉及代碼。他們確保代碼覆蓋規範，因爲如果代碼不包含規範，代碼將會通過測試。你有任何額外的代碼並不重要。

因此，當測試看起來像他們描述了您或利益相關者的所有期望時，您有足夠的測試。

Answer 13

肯特貝克的建議是寫測試，直到恐懼變成無聊。也就是說，直到你不再擔心任何事情會中斷，假設你從適當的恐懼水平開始。