我該容忍多大限度的預先設計？
在寫測試的時候，可能必須構建出接口和一些類來讓代碼編譯通過——這一步該跨多大？
Chad Meyers寫下了一些他在開始接觸TDD實踐時碰到的疑惑和問題，它們應該都是比較常見的：
我該容忍多大限度的預先設計？你怎么知道應該何時停止（也就是說，“當人們開始討論算法，就是該測試的時機了”）？
對于象“我心里清楚我們需要這個”這類東西——我們該如何處理（例如，在控制臺main()方法中加上一個try/catch{Console.WriteLine(ex);}？）
編寫測試時，為了讓代碼編譯通過，你不得不寫下一兩個接口，一個實體類，在類中還有一些NotImplementedExceptions等等。這一步該走多遠？
如果在測試一個用戶故事期間，你發現先前的預先設計有問題，你是會馬上停下來跟你的搭檔討論，做該做的事，然后繼續；還是折返回去，在當前的故事中采用完整的測試優先模式？
在處理一個新的用戶故事時，你發現針對前一個故事所編寫的測試已經不再體現需求。你是否會立刻重構那個測試，還是把它標記為“忽略”，等你完成當前的故事再回過頭去處理那個被忽略的測試？還是有其它做法？
如果新的用戶故事要求對某個已有的測試做出輕微調整，你是會調整它，還是會寫一個新測試，把舊的扔掉（也就是，“不許更改現有的測試代碼！”，或者“只有出現小的編譯問題時才準動它，否則就別碰！”）？
如果你構建了模型并且通過了測試，但是你發現這個設計很幼稚，而且即將要做的用戶故事肯定會對其進行重大修改，并生成一個新的完全不同的模型。你是應該退 一步，考慮進行大型重構嗎？還是應該繼續修修補補，調整現有的模型，盡管這個模型最終會被目前看來顯然超出該用戶故事范圍的工作所改進？
Derick Bailey分享了他對Chad這些問題的看法。他很謹慎的說，這些都是基于他自己的親身體會，所以你的實踐經驗可能會跟他的不同。下面是他的回答：
知道自己應該構建什么就行。
這個問題實際上應該根據你的實際項目來回答。我最近做了一個企業集成項目，里面用到了我們的核心維護系統，然后添加了一些離線操作功能。在這個項目中，我 沒有做太多的預先設計。我知道系統需要能夠在離線模式下操作，我還知道即使是沒人登錄計算機或者運行這個軟件時，它也需要能夠執行一些操作，我知道它需要 跟主維護系統進行雙向通信，用來執行與維護相關的的一定數量的任務。我從一些設想/預先設計開始動手——構建了一個Windows Service來運行核心進程，構建了一個客戶端-服務器架構來托管UI，在一個消息系統上為通信提供支持。除了這些算是預先設計以外，在構建軟件的過程 中都是其他各項任務的功能需求來驅動項目設計的進展。
最近，我與一個為實驗室開發某系統的團隊一起工作時，有了截然相反的體驗。我們有源于客戶的需求，客戶所要求的流程，以及對客戶手中數據進行轉換的需要； 我們需要一個大規模的預先設計，用以判斷我們的解決方案可以滿足數據轉換和功能需求。系統的核心設計是預先完成的，但是具體實現還是在開發過程中慢慢成型。
如果你還是TDD新手，這些問題可能會聽起來很熟悉。這些問題的最佳答案應該到先行者那里去尋找，他們可能存在于某個本地用戶社區，或者眾多在線的開發者郵件列表中的一個。換個角度來說，如果你已經有了充分的TDD經驗，請與大家分享一下你對這些問題的答復。
文章來源于領測軟件測試網 http://www.kjueaiud.com/