什麼時候應該選擇測試驅動開發？

Question

我的問題與標題相同。我還沒有完成測試驅動開發，我已經完成了單元測試，並且我知道一般的測試，但是我聽說遵循TDD是非常有利的。所以我應該每次選擇它，或者是否有一些先決條件...我只需要知道一些基本或重要的要求，當我應該選擇TDD。對不起，如果這個問題太微不足道了。

Answer 1

我會說，只要你是一個項目編碼。通過這個，我指的是你希望生成的代碼將被人們使用。這基本上都是代碼，除了你正在學習和發現新技術的研究外。

即使您認爲該項目只是一個小項目，但事情往往會不受控制地加速失控。當你發現自己不得不重構大量代碼時，你會爲測試感到高興。

另請注意，tdd不僅僅是測試。這是一種鼓勵您創造清潔和堅實設計的發展方法。

當你開始tdd的一切。一旦你有更多的經驗，那麼也許你可以退縮，並確定何時不tdd。

Answer 2

恕我直言，如果你不熟悉TDD，試圖將其應用於需要交互/使用遺留代碼的項目中，它比從零開始在項目中應用它要複雜得多。事實上，關於這一點有一個完整的book。

HTH

Answer 3

我的建議是儘可能多地使用單元測試。

警告：根據我的經驗，TDD在使用已經有一定經驗的技術時效果最好。如果您不確切地知道所需的結果是什麼樣子，那麼編寫測試斷言通常很困難（例如，如果您從未在您的整個生活中從未編寫過操作方法，請嘗試爲ASP.NET MVC操作方法編寫測試）。在這些情況下，你可能最好在實現代碼後編寫單元測試。

Answer 4

如果我正在開發沒有用戶界面的東西，我現在總是使用TDD。畢竟，你必須測試軟件。你既可以做額外的工作，也可以做TDD，或者你可以做額外的工作，並將用戶客戶端混合在一起進行測試。前者更徹底，更可重複地進行測試。

另一方面，針對用戶界面代碼做TDD並沒有真正爲我提供太多價值。出於各種商業原因，我僅限於開箱即用的Visual Studio工作，使用VS「錄製」測試是一個巨大的時間，特別是如果您更改UI時必須重新錄製它們。我爲TD背後的業務邏輯做TDD，但不是UI本身。