我們現在怎麼介紹TDD？在成熟的項目中引入測試驅動開發（TDD）是否可行？
嘲笑似乎是要走的路。但是我們在這裏需要做的嘲笑似乎太多了。聽起來像需要爲現有的工具（BO，數據庫等）工作的嘲笑系統開發精心設計的基礎架構。
這是否意味着只有從頭開始時，TDD纔是一種合適的方法？我有興趣瞭解在已經成熟的產品中引入TDD的可行策略。
創建一個複雜的模擬基礎設施可能會隱藏您的代碼中的問題。我會建議您從集成測試開始，使用測試數據庫，圍繞您計劃更改的代碼庫的各個方面。一旦你有足夠的測試，以確保你不會破壞任何東西，如果你做出改變，你可以開始重構代碼，使其更容易測試。
另外，Michael Feathers出色的書Working effectively with legacy code，對於任何想將TDD引入遺留代碼庫的人來說，它都是必讀的。
是的，你可以。不要一次完成所有工作，而只需介紹觸摸它時需要測試模塊的內容。
您也可以從更高水平的驗收測試開始，然後從那裏開始工作（爲此，請看Fitnesse）。
我認爲將TDD引入現有的應用程序是完全可行的，實際上我最近自己做了。
以TDD方式編寫新功能並重構現有代碼以適應此問題最爲簡單。通過這種方式，您可以開始測試一小段代碼，但效果開始在整個代碼庫中傳播。
如果你有一個bug，然後編寫一個單元測試來重現它，必要時重構代碼（除非這個努力真的不值得）。個人而言，我不認爲有必要瘋狂嘗試將測試改裝到現有系統中，因爲這可能非常乏味而沒有大量的好處。
總之，從小處開始，您的項目將變得越來越受到感染。
編寫有關bug的新單元測試效果很好。你沒有一個「完整的」測試套件，但你有一些東西可以建立。 – 2008-09-20 20:31:58
是的，你可以。從你的描述來看，這個項目處於良好的狀態 - 功能測試自動化是一種可行的方法！在某些方面，它比單元測試更有用。請記住，TDD！=單元測試，這都是關於短迭代和可靠的驗收標準。
請記住，擁有一個現有的和被接受的項目實際上使測試更容易 - 工作應用程序是最好的需求規格。所以，你比一個只有一紙廢紙的人處在一個更好的位置。
剛開始使用TDD開始處理新的需求/錯誤修復。請記住，切換方法會產生開銷（確保你的客戶意識到這一點！），並且可能期望習慣於「古老的方式」的團隊成員有很大的不情願。
除非您需要，否則請勿觸摸舊的東西。如果你有一個會影響現有資料的增強請求，那麼請花費額外的時間來完成額外的設置。
個人而言，我沒有看到多少價值的引入對實物模型，複雜的基礎設施 - 肯定有一種方法可以實現一個輕量級的模式相同的結果，但它顯然取決於您的具體情況
對於「TTD！=單元測試」+1，現在我將修復該錯字。 – Johnsyweb 2011-06-07 12:28:43
我將開始進行一些基本的集成測試。這將得到其他員工的支持。然後開始分離具有依賴關係的代碼部分。努力使用依賴注入，因爲它會使您的代碼更加可測試。將錯誤視爲編寫可測試代碼的機會。
可以幫助您測試遺留代碼的一種工具（假設您不能\沒有時間重構它，是Typemock Isolator：Typemock.com 它允許在現有代碼中注入依賴項而無需提取接口因爲它不使用標準的反射技術（動態代理等），而是使用分析器API來代替。 它被用來測試依賴於Sharepoint，HTTPContext和其他有問題區域的應用程序 我建議你看看。 （我作爲該公司的一名開發人員工作，但它是唯一一個不會強迫您重構現有遺留代碼的工具，可以節省您的時間和金錢） 我還強烈建議「使用遺留代碼進行有效工作」獲取更多技術。
Roy
感謝您的建議。它看起來就是我所尋找的。 – rpattabi 2008-09-20 11:41:00