試圖在不熟悉域的情況下使用TDD

Question

背景：

我目前正在爲學習目的創建我的第一個遊戲引擎項目。這是我做過的第一個更大的項目。我知道在項目中涉及遊戲引擎（比如分離的系統 - 輸入，圖形，音頻，物理等）的更高層次的細節，但是當進入細節時，我很喜歡弄清事物隨我走。我的編碼過程，現在看起來是這樣的：

1）找出我想設計

2）啓動一些實驗性的編碼看到的東西需要究竟是如何工作系統的一些快速的，更高層次的細節

3.）一旦我對自己所擁有的東西感覺良好後再添加測試。

由於我對問題領域（遊戲引擎編程）非常不熟悉，我發現我確實需要在代碼中進行實驗，以查看我需要哪些功能以及哪些設計套件最好。然而，我知道大多數社區（所以似乎無論如何）通常提倡更多的TDD方法來構建應用程序。我可以看到這樣做的好處，但我不太清楚，當我真的不知道我真的需要測試哪些功能時，我會如何應用「先寫測試，再失敗，然後通過」。即使我能想到1或2個確定的函數，如果在實驗階段，我發現將這些函數分成不同類的更多函數更好。然後，我將不得不不斷重新設計我的代碼和我的測試。

我的問題/問題（S）：

那麼，有沒有方法可以使用，當你在代碼中嘗試TDD方法的好辦法？或者，TDD通常是指那些熟悉他們工作項目的人，並且瞭解設計需要什麼或者他們需要測試哪些功能？

Answer 1

一種常見的方法時，使用不熟悉的領域TDD：

• 做一些實驗性的編碼，以瞭解更多
• 預留的實驗代碼並啓動TDD「測試第一」的方針
• 當你寫生產代碼讓你的測試通過，你將會收穫你的實驗代碼。

這種方法的好處是，通過TDD「紅色，綠色，重構」循環，您通常會改進實驗代碼的設計。沒有它，你的實驗代碼通常會變成一個「大泥潭」。

Answer 2

我發現當我讓「我不習慣在這種情況下編寫單元測試」成爲不寫單元測試的藉口......我從不寫任何單元測試。

如果您對代碼行爲有足夠的瞭解，您就足夠了解它的測試。

即使我能想到的1個或2個明確的功能，如果在 試驗階段，我覺得這是更好地跨越不同類別

如果你已經 拆分這些功能伸到更多的功能原始功能已經過測試，而且你只是在改變界面，那麼應該有一些測試邏輯不得不改變。之後改變界面時沒有任何破壞的風險。此外，這種擔憂並不是專門針對新領域的實驗。

也許陌生的領域不是開始學習TDD的最佳場所。但我肯定不會說這個過程本身不適合。