C＃ - 原型開發時TDD的策略

我發現某些形式的編寫代碼比TDD更適合TDD。尤其是紅綠重構測試。C＃ - 原型開發時TDD的策略

在紅色/綠色重構中，我從所有單元測試開始，並且失敗（紅色）。然後我執行我的代碼，直到所有測試都通過（綠色）。

例如，如果我有一個需要實現10-20x的接口，那麼我只需在一個類中實現接口，該類將所有方法設置爲拋出NotImplementedException。然後，爲每個公共方法創建一個測試。從那裏，我只寫代碼來修復測試。

流程並不總是那麼簡單。例如，我正在編寫一個基本的Excel解析器。我不熟悉Excel Interop API。我發現簡單地編寫代碼更容易。然後，通過試驗和錯誤，我發現我的班級設計。

在這種情況下，我正在寫一些垃圾軟件。將其原型化，以便我能弄清楚我的設計需要什麼。（也許我需要在這裏傳遞一個fileName，也許這個構造函數......）。

最終，我想保持TDD。我相信這會使我的代碼最小化，並且lean。

TDD是否適用於原型設計？換句話說，我有沒有一種方法可以讓TDD爲我工作，即使我不完全確定我的設計在哪裏？

對於這種類型的問題，我相信你想用BDD而不是TDD來處理它。 http://en.wikipedia.org/wiki/Behavior_Driven_Development – Druegor

掌握技術的一大部分是知道何時應用它。在學習技術的過程中，將它應用於各種問題是非常有價值的，這樣你就可以獲得經驗。然而，一旦你獲得了這些經驗，你就可以評估任何給定的問題是否適合你所處理的每種技術。如果使用TDD發現原型設計的效率較低，則無需在此情況下使用它。 –

讓我先說明我自己沒有在TDD中找到價值。然而，我對「TDD」原則的理解是你寫了一個失敗的測試 - 然後編寫足夠的代碼以使其通過。你接近這一點的方式是編寫所有的測試，然後編寫代碼讓它們全部通過。我不確定那會「驅動」你的設計。 – tsells

是的，但做它就像一個API。不要猜測如何用excel做些什麼，而要決定你想做什麼以作爲最終結果。（例如：讀取單元格A0到A100）

然後，當您繼續瞭解它如何在該界面後面工作時，您將最終看到它是什麼，您可以自行分離並測試，並且可能會更好地工作爲設計。（例如：編寫代碼讀取0,0到0,100，並刪除字母代碼，因爲它更復雜，沒有任何增益）

不要害怕由於設計/行爲改變而使測試失效，他們在那裏幫助，而不是具體的。（例如：應該刪除單元格A0到A100的原始測試）

2011-10-12 21:17:06 Rangoric

恕我直言，你將有兩個選擇：

很肯定的人有更多的建議，但這些都是我的兩個最喜歡的辦法

2011-10-12 21:15:40

回答