九、需要人工干預的測試
自動對系統進行檢測是測試的一大優點。它可以確保不因爲個人的疏忽而遺漏對某些方面的檢查，同時不增加程序員的工作量。某些情況下，會有相當的誘惑使你想要簡單的輸出結果來通過人工來比較，比如文件的內容或界面佈局等。人一眼可以看到的問題，可能需要費相當的功夫才能寫成測試的判斷。但是要記得，測試的成本並非只是寫它的時候付出的努力，同時還包括每次執行時你需要作的工作。所以，讓它儘可能的傻瓜化，你就會越多的執行它，它對你的幫助就會更大。
對這種較爲複雜的問題寫測試的另一個好處是可以仔細的讓自己想想到底想要保證什麼準則不被違反，需要測試的是什麼？
我碰到的另一種需要人工干預的情況是測試的過程中包括了一個需要用戶輸入的模態對話框，整個流程會停止，直到接收用戶的輸入爲止。這樣的測試如果用在DailyBuilding中簡直就是災難。引起它的原因是測試的邏輯與界面操作沒有分離。
八、複雜的測試配置環境
有沒有試過爲了測一個方法，必須得先生成2個全局的單體對象，再設置10個局部變量。在每個TestCase的Setup和TearDown裏都是大堆的生成測試環境的代碼。造成這種情況的原因是在被測對象內部的代碼之間依賴於全局的對象和變量。應該通過接口將這種依賴顯式規範出來。
七、牽一髮而動全身的測試代碼
改了一個類輸入輸出的約定後，你發現有20多個測試用例都被打破了。更糟的是，你發現每次這樣的改動都會面臨同樣的問題。
耦合的測試反映的是耦合的程序結構，需要採取各項解耦的方法來使變化的範圍不致於蔓延。另一個造成這種問題的原因是測試的代碼在測試實現而非意圖。這樣當程序的內部行爲變化的時候，測試也不得不隨之改變。這種情況在給已有的代碼添加測試時特別容易發生。
六、針對代碼而非功能的測試
有沒有見過對一個相加方法寫出上百句的測試？包括了各種可能的取值組合和各類邊界情況。或者看到一個複雜的測試過程，像爆米花一樣上下翻飛各種數據，但是你卻還得通過過程含混不清名字來猜測它的意圖究竟如何。
測試驅動開發並非測試，不必責備求全覆蓋所有的測試情況。好的測試應該清楚的表達你希望程序達到的意圖，並保證程序真的符合這些意圖。
五、巨大的TestCase
TestCase對應程序中的一個模塊，一般來說是一個類。過於龐雜的TestCase說明對應的類的職責過多，應該參考《重構》中抽取類的方法把它進行分解。
另一種情況是這個TestCase對應的類提供整體的服務，而在內部調用其他對象的操作。如果僅僅在最外層進行測試，往往有很多內容要測，並且需要考慮每個部分的不同情況的組合。對這種情況，需要用接口顯式的定義這個類和其他局部的委託關係，再通過虛擬對象隔離兩者進行測試。
四、紅燈常明
失敗的測試表示系統中有某項約定已經被打破了，因而爲了保證系統的正常運行，必須儘快修正這一問題。坐視某個測試沒有通過往往是由於這個測試已經不適合現在的程序結構了（事實上，這是由於另一個錯誤，先寫代碼再寫測試引起的）。對這個測試進行修改，或者乾脆刪除它。喪失了對紅燈的警覺就等於喪失了測試驅動開發的大部分好處。
三、大跨度的測試
提供了系統最外層的輸入，然後就變魔術般的輸出最終結果。作爲驗收測試是適當的，而且往往寫下的第一個測試就是這樣高層次測試。但是，如果僅僅有這種測試是不夠的。需要有更多的說明產生這一結果的機制的測試代碼。
判斷測試跨度的一個標準就是，每個測試應該在幾小時內得以通過（我的極限是一天，不同的人可能適應更小的粒度）。如果寫下一個測試後需要奮鬥一週的時間纔看到結果，那麼TDD對你不會有太大的幫助。應該儘快的通過虛擬對象通過高層測試，並將注意力集中到更低層次對象需要滿足的測試上。
二、衣不蔽體的測試
有些上萬行代碼的工程中僅僅有2、3個TestCase，往往是對某些“核心”模塊或複雜算法所作的。或者僅僅是某個人試試IDE的新功能的結果。這樣的使用方式根本和測試驅動開發不沾邊。測試用例並不是一條安全索，而是類似腳手架那樣，是設計和實現的手段和一個組成部分。
我很幸運，基本上前面提到的錯誤都曾犯過，而且可能還會再以後還會再犯各種不同的錯。然而我感覺這些錯誤都不如那最大的錯誤：
一、不寫測試
有很多理由可以用來拒絕TDD：進度太緊，哪有時間寫測試；這種方式太古怪，無法接受；你所從事的領域過於特殊，並不適合測試驅動開發的方式；有些代碼根本寫不出測試……
接受“人是會犯錯的”這個事實（不論是在寫程序，還是在應用新的開發過程的時候），並面對這些錯誤、研究它們，定義它們、檢查並且清晰的反饋結果。最終，也許你會發現當初的恐懼已經隨着一步步的深入煙消雲散，而你的腳步也早已擴展到了原來未曾涉及的領域。