我不確定「先測試」是如何工作的，我想聽聽有關何時以及爲何採取這種方法的爭論。在執行之前沒有/要寫測試嗎？
我聽說在編寫單行執行程序之前，經常建議編寫測試和模擬事情。但是，我不禁認爲它不適合所有情況。例如，假設我正在製作一個原型，而且我不確定所有事情如何運作。所以我只是開始找到我認爲需要的每個步驟的示例並將它們投入到我的代碼中。最後，我證明了我的理論，並沒有那麼長時間。這實質上是「我的考驗」。這不是一個單元測試，但它是一個測試（很可能它是一個控制檯應用程序）。
這幾乎是我的工作方式。我想想我想做什麼，並嘗試去做。如果它有效，我最終會回去編寫單元測試，這樣我就可以陷入迴歸。這與你「應該做的」不同嗎？
的涵蓋範圍廣泛的規則是：先做最危險的項目。
首先做的測試案例隱含地認爲編碼的風險最大的部分是錯誤的溝通和誤解正在創建的對象的接口和行爲。
對於很多項目來說，這很可能是真實的，TDD在這些情況下非常合適。
但是，在許多不是這種情況的項目中，在這些情況下應用TDD是一個糟糕的選擇。
如果您的最高風險是可用性，請停止使用單元測試並做一些UI原型設計。
如果您的最高風險是性能，請先做一些性能原型，並且不要擔心接口。
此列表繼續。
先做風險的項目有許多優點：
項目，這些項目不可避免地註定早點死，許多資源被浪費了。
那些陷入困境但可挽救的項目可以讓項目管理人員儘早做好準備。
貴組織的業務方面在失敗風險較低時將重視項目;它不太可能會被不必要地提前取消。
這很簡單，答案是在原型製作過程中。在這個階段，你並不瞭解你的系統足夠好，以便正確測試，反正好的做法是說原型代碼應該是丟棄代碼，所以在這個階段測試不會給你任何實際的好處。但從原型設計中閃現的理解能幫助你，所以一旦你進入生產，你就可以進行有效的測試。
所以，是你的做法是正確的，如果你做的原型
後測試我發現寫作測試首先不能很好地工作，當我還在構建我的代碼的「故事」。當我不確定接口是什麼樣的時候，很難編寫測試。我可能會編寫存根代碼來充實類和接口，而不用考慮測試。但我儘可能快地嘗試進行測試。如果我在構建設計時記錄下要測試的內容，然後在設計更加紮實時回到我的筆記並首先進行測試，那麼我覺得這很有幫助。這通常意味着實現和單元測試代碼一起成長，兩者都沒有。
「我聽說在編寫單行執行程序之前，經常會推薦編寫測試和模擬事情......我最終回去編寫單元測試......這與你」應該做」？」
既然你剛開始回答自己的問題，那麼你是不是真的在問這個問題呢？
有很多原因爲什麼人們回答自己的問題 。有時候，這是一種爭論的方式。
它允許人們說「我不是在爭論，我是 只是問爲什麼這是錯誤的」。
的目標是測試第一。這是它的工作原理。
假設我正在製作一個原型，但我不確定一切事情如何工作。
但是，我知道一件事。它應該做什麼。
寫下它應該做的具體事例。具體的具體投入和產出。
這就是測試案例。我先做了。我可以將這個形式化爲單元測試嗎？可能不會。但是，我從一個驗收測試案例開始。
現在，我可以將問題分解成幾部分。
所以我剛開始找到我認爲需要的每一步的例子。
對於我認爲需要的每一個例子，我都記下了該步驟的內容和結果。
這些都是測試用例。我先做了他們。在很多情況下，我可以將這些形式化爲單元測試。
一旦我進行了測試，我會回到每個步驟的示例並將其放入我的代碼中。
我做了測試，然後編碼。我沒有做任何編碼之前的所有測試。我首先進行了測試，但沒有采用瘋狂的全測試無代碼方式。我以一種小代碼的方式進行了增量測試。但一切都是先測試。
沒有一個「正確的方法去做」。不過，我確實認爲測試驅動開發（TDD）可以幫助您解決這個問題。我發現首先編寫測試有助於塑造API並使代碼更清晰。當你首先編寫測試時，首先考慮如何在調用代碼之前（接口，或者'該做什麼'），然後再考慮實現（'我該怎麼做'）。
例如，假設創建CRM模塊。你可能會認爲首先要做的就是讓花費最多的客戶。所以，你會寫一個測試：
Assert.AreEqual（Customer1，crm.GetMostValuableCustomer（），「最有價值的客戶不是預期的」）;
然後你可能會喜歡的東西如下：
Assert.AreEqual（新客戶[]， 「GetCustomersByValue（）並不如預期」{customer1表，顧客2，Customer3}，crm.GetCustomerByValue（））;
所以，關鍵是你想從不同的角度的代碼（如消費者，而不是生產者）。我相信可以幫助我編寫更清晰的代碼，而且我不必稍後返回並創建迴歸測試。我希望我有一個更好的例子，但希望你能看到在這個方法中的工作如何可能實際上幫助你在原型階段。
我覺得你不是測試穗/原型的方法是就好了。但有兩個思路：
一旦你完成你的原型，你知道你正在做的事，無論是把它扔掉，並重新實現它第一次測試，或寫試驗，您對代碼已經寫好。
當你有更多的實踐瓦特/單元測試，你會發現它更快地在測試創建原型不是創建一個控制檯應用程序。我不是說創建一個測試和一個單獨的課程/這個想法，我的意思是在測試方法中探索w/code。我已經做了很多次了，我對此非常滿意。當我正在學習一個新的API或甚至是一門新的語言時，測試爲我提供了嘗試實驗的最快反饋週期。然後，一旦代碼正在工作，我可以將其提取到一個單獨的方法/類中，成爲真實系統的一部分。
即使你正在編寫一個扔掉原型它仍然是想在什麼樣的原型會怎麼做方面是有用的，並與確認它的測試開始。確保原型能被測試也將形成解決方案的接近方式。
然後，當代碼被扔掉你還有測試。
我也有麻煩開始了樣機進行試驗，但是當我已經成功地做到這一點我一直很高興我做到了。
人們還可以爭辯說，原型是實現的一部分，因此，當你已經有了一些簡單的API在其上運行的基本測試應該只發生。這樣，您首先會發現您希望如何使用您的系統，這是TDD的優勢之一。 – Franck 2008-11-26 01:53:18