在測試驅動開發中，你是否先編寫每一個可能的測試，然後編寫代碼？

Question

在做測試驅動開發時，我一直習慣於先寫一個新功能的第一個單元測試，然後編寫該功能的代碼。如果我有額外的測試來編寫以涵蓋所有場景，我通常會在寫入代碼後編寫它們。這被認爲是不好的形式？在編寫代碼之前，我是否應該先嚐試寫一些功能的所有可能的測試？

Answer 1

爲了正確完成TDD，你總是先寫測試，然後再寫功能。

爲了補充一點，我一次只考慮一個場景，不要寫20個測試，然後爲這20個測試編寫代碼。寫一個測試，紅色/綠色標誌，然後繼續下一個測試。這確保您也正在執行TDD的核心原則之一，即實現儘可能最簡單的實現，以滿足您的所有需求/方案。

Answer 2

其實不，我經常發現功能「在這去」。讓我進一步解釋「否」：

我通常開始爲高級功能編寫測試用例，定義它的接口。之後，我通常將此測試設置爲忽略並繼續爲每個接口功能編寫測試。我的週期是這樣：

1. 集成測試的故事（高級API）的調用集成測試
2. 實現方法（紅/綠/重構）
3. 重複方法XYZ
4. 編寫單元測試2 + 3直到集成測試通過。

雖然這樣做，我經常意識到我已經忘記了我的主要測試中的一些小功能。然後我通常會花時間回顧我的客戶需求。如果它合適，我會回去添加一個測試，因爲我首先想完成我開始的任務。

有時我會看到重構的機會。我通常會完成一個實現，直到達到提交點，然後進行重構，但是有時我會隱藏自己的更改，然後返回並首先執行重構（包括新的測試，如果需要的話）。 Mercurial MQ的這個工作流程是powererd。

Answer 3

越早寫出測試越好。我通常發現編寫測試比實際執行功能更困難，因爲您必須瞭解所有可能的結果。所以我傾向於在「在區域內」時寫更多的測試。而在編碼期間，我意識到我可能錯過了一個測試案例，我只是注意到了待辦事項列表。

所以在我看來，這取決於你的休閒，但我會實施多批次的測試。

Answer 4

對於大多數人來說，TDD和增量/敏捷開發是一致的。這看起來是這樣的：

1. 編寫一個測試的一些功能
2. 編寫足夠的代碼以使測試通過，重構需要
3. 重複。

如果你碰巧有一個詳細的規範提前，你可以先寫所有的測試，但你必須忍受一段時間沒有通過測試。

Answer 5

TDD的要點是，當功能尚未實現時，您必須觀察測試失敗。所以你必須在代碼之前編寫測試。

Answer 6

當你進入TDD節奏時，你一次寫一個測試並使其工作。很短的紅綠重構週期真的感受到節奏。也就是說，其他方法沒有什麼不妥（對於某些類型的問題，它們甚至可能更有意義），但通常你需要做的關於你正在考慮的其他測試的唯一方法是將它們寫下來（或者讓你的對如果你是結對編程寫下來），所以你不要忘記他們。無論如何，你必須這樣做，因爲你可以在寫一個不同的測試時忘記測試。

Answer 7

我看到它的方式，測試驅動開發並不一定是測試第一個開發。您的測試可以推動您的開發，並且您在開發應用程序時確實正在編寫測試。你首先編寫一個簡單的測試失敗，因爲你還沒有編寫功能。然後你編寫你的代碼來實現測試通過。

然後你回到你的測試，進行修改，這將迫使你添加更多的功能或重構你的代碼，以遵循更好的做法或減少重複代碼，去修復你的代碼，使測試通過...重複，重複，重複。

一對夫婦的視頻演示，這是下面，雖然你也許可以找到很多更通過谷歌搜索「TDD視頻」

http://agilesoftwaredevelopment.com/videos/test-driven-development-basic-tutorial （哎呀，只有一個視頻，新用戶不能插入多鏈接）

Answer 8

做足夠的測試，一次測試1個單位的代碼，然後寫實際的代碼，直到它通過測試..漂洗，洗滌，重複，直到完成。

如果你發現自己需要爲一個單元的代碼（一個方法，一個函數等等）編寫許多測試，這可能是你試圖在該單元中做太多的一個標誌......這反過來又使得單元難以測試&以後再重構。

Answer 9

我嘗試在每個功能位之前的某個級別編寫測試。有時，我必須編寫更多的代碼才能通過編譯器，但我試圖將其最小化。首先寫測試意味着我在寫代碼之前已經考慮過代碼應該達到什麼。

我發現有用的一種技術是保持索引卡或記事本的方便，並記下我一路上想到的所有情況。這使我能夠專注於當前的任務，而不會丟失所有我應該考慮的其他事情。之後，我可以通過列表工作，並完成額外的案例，或者放棄它們，因爲沒有必要。

Answer 10

你可以這樣做，但你不會做TDD。這個問題（無論如何，其中之一），首先寫出所有的測試結果是，在任何需求不平凡的情況下，您的測試將建立在很多關於代碼結構的假設中，重新試駕。大步驟導致失誤。

成功的TDD的關鍵之一涉及採取小步驟。當出現問題時，小步驟意味着更少的更改退出。小的步驟意味着你可以更頻繁地瞭解你正在做出的改變的效果。而且因爲小步驟更容易放心，所以它們會增加速度的矛盾效應。

TDD循環從需求開始。首先選擇一項要求，通過幾個簡短的步驟即可知道如何通過測試立即進行定義。如果你看一個需求，而你不確定如何測試它，或者你認爲，「是的，但要做到這一點，我需要[先插入不明確的步驟]，然後你應該跳到另一個要求你知道該怎麼做，或者你應該把這個要求分解成你知道該怎麼做的更小的需求。編寫一個量化部分需求的測試（「紅色」，因爲它失敗了，因爲它還沒有實現來測試），因此，編寫能夠通過測試的任何代碼（「綠色」），然後重新編寫代碼以消除重複，幻數和其他代碼異味（「重構」）。在重構階段，您應該繼續小步工作，經常重新運行測試以確保您沒有損壞任何東西。繼續這個循環，直到你能夠看清你的老闆/客戶，並且滿足要求。

現在您已經定義了一個簡單的系統部分，您已經打開了需要實現的需求列表 - 與您剛剛實現的需求相鄰或依賴的需求現在可以在較小的按照你已經完成的步驟進行步驟。

所以所有的結果是：不要試圖一次性做所有的測試。一次（小）一件事。